perm filename PRO2[AP,DBL] blob
sn#067845 filedate 1973-10-20 generic text, type T, neo UTF8
00100
00200
00300 PROTOCOL FOR AUTOMATIC PROGRAM WRITING SYSTEM
00400 WRITING A CONCEPT-FORMATION PROGRAM
00500 (SIMILAR TO WINSTON'S PROGRAM)
00600
00100
00200 This protocol will be structured around the flow through the PUP
00300 system. Thus it will appear very similar to the ultimate QLISP-type
00400 trace. Function names appear as CAPITALS, and comments are in normal
00500 lower case. Indentation corresponds to function call depth; two spaces
00600 for each level.
00700
00800 SERVE
00900 This function is the starting point of the PUP system. Its name reflects
01000 the fundamental drive of any puppy: to serve its master. Serve sees that
01100 nothing is being done, and calls OBTAIN:USABLE:INFORMATION repeatedly,
01200 until the latter returns something which can be considered a task.
01300
01400 OBTAIN:USABLE:INFORMATION
01500 This function decides which of TRANSLATE, GET:NEW:INFORMATION,
01600 ANALYZE:IMPLICATIONS, and EXTRACT:RELEVANT:SUBSET
01700 to attempt in the present situation. It affects this by calling CHOOSEFROM.
01800
01900 CHOOSEFROM
02000 This function evaluates each possibility and picks the best one.
02100 It knows that when choosing among functions, we should examine the
02200 "when" part of each function description, to see how relevant it is.
02300 If some functions tie for tops here, we see how hard it would be to
02400 satisfy each's preconditions. If we still have a conflict, we pick
02500 the function easiest to implement usually.
02600 In our present vacuous situation, only GET:NEW:INFORMATION is relevant.
02700
02800 GET:NEW:INFORMATION
02900 This requires, as a precondition, that PUP know the specifics of
03000 what new information it wants.
03100
03200 SPECIFICS
03300 In our present case, this function is trivial, since PUP merely
03400 wants any type of command.
03500 end of SPECIFICS
03600
03700 Now GET:NEW:INFORMATION continues. It asks that a message be
03800 printed to the user, informing him of the specifics of what is wanted.
03900
04000 MESSAGE
04100 Prints out something like "PUP: I want any task"
04200 end of MESSAGE
04300
04400 Pup now reads in what info. was requested. Assertions, to the
04500 effect that we have some new information, are made.
04600 end of GET:NEW:INFORMATION
04700
04800 end of CHOOSE:FROM
04900
05000 end of OBTAIN:USABLE:INFORMATION
05100
05200 We are now back in Serve. Suppose the user has typed in:
05300 "Write a program which does concept formation"
05400 This is our new information. We test to see if it is executable;
05500 that is, whether ∃ function named WRITE which can meaningfully
05600 take the six arguments a, program, which, does, concept, formation.
05700 This of course fails, so we repeat OBTAIN:USABLE:INFORMATION.
05800
05900 OBTAIN:USABLE:INFORMATION
06000 Once again, we choose from the four possible functions.
06100
06200 CHOOSE:FROM
06300 Since new information exists, GET:NEW:INFORMATION is no longer
06400 the ideal choice. This time, TRANSLATE wins.
06500
06600 TRANSLATE
06700 This is accomplished by breaking the info. up into a few pieces,
06800 and looking each piece up in our dictionary. If it were done in a
06900 better way, I would call it parsing. The crude mechanism is to
07000 backtrack until we succeed or else until all possible break-ups have
07100 been tried.
07200
07300 PARSE
07400 This (eventually) breaks the info. into
07500 (write a program which does) (concept formation).
07600 end of PARSE
07700
07800 LOOKUP
07900 Recognizes (write a program which does) as a call to the
08000 known system function WRITE:PROGRAM.
08100 end of LOOKUP
08200
08300 LOOKUP
08400 Recognizes (concept formation) as the subject CONCEPT:FORMATION.
08500 For uniformity, all topics are built in as procedures. So this is just
08600 a call to the function called CONCEPT:FORMATION.
08700 end of LOOKUP
08800
08900 Translate now examines EXTRACT:RELEVANT:SUBSET, to see whether
09000 or not to apply that function to the translated information. But this
09100 isn't applicable unless the information is very large in size, which
09200 it is not. As a post-requisite, Translate sees whether the translated
09300 information is usable as it is. If not, it may call itself recursively.
09400 But (WRITE:PROGRAM (CONCEPT:FORMATION)) is usable, so we are done.
09500 end of TRANSLATE
09600
09700 end of CHOOSE:FROM
09800
09900 end of OBTAIN:USABLE:INFORMATION
10000
10100 Serve again examines the information. This time, it is executable,
10200 so its final action is to execute the information.
10300
10400 WRITE:PROGRAM
10500 This function is now called, with the task it is to do (its argument)
10600 set to CONCEPT:FORMATION. We check that the ability to do the task does
10700 not already exist. Then we get the name the user wishes to call the
10800 program.
10900
11000 GET:NAME
11100 The first step, since PUP is smart, is to generate a set of plausible
11200 names for the task.
11300
11400 PLAUSIBLE:NAMES
11500 From CONCEPT:FORMATION we generate the plausible names
11600 using initials, mainwords, firstfew, and compositions of the
11700 preceding. In this case: CF, C, CONCEPT:FORMATION, CONCEPT.
11800 Next we eliminate all previously-known identifiers from this list.
11900 Say CONCEPT:FORMATION is in our dictionary, and C is a known constant.
12000 We thus return the two names CF and CONCEPT.
12100 end of PLAUSIBLE:NAMES
12200
12300 The second precondition for GET:NAME is that the user be aware of
12400 the plausible names for the task. PUP searches its list of functions
12500 for one which makes the user aware of some given fact.
12600
12700 MESSAGE
12800 We print something like "The plausible names for the task
12900 (CONCEPT:FORMATION) are CF and CONCEPT."
13000 end of MESSAGE
13100
13200 Pup now begins to execute GET:NAME proper. First a note is printed.
13300
13400 MESSAGE
13500 Prints "What does user wish to call the task (CONCEPT:FORMATION)?"
13600 end of MESSAGE
13700
13800 Next GET:NAME reads in the user's reply. Say the user types
13900 "CF". We then assert that PUP and the user may now refer to the
14000 task as CF. That is, the name of the program PUP is going to write
14100 is CF.
14200 end of GET:NAME
14300
14400 The next prerequisite of WRITE:PROGRAM is now satisfied:
14500
14600 MESSAGE
14700 Prints "PUP: I am ready to begin to write CF program to do
14800 CONCEPT:FORMATION."
14900 end of MESSAGE
15000
15100 The final prerequisite to WRITE:PROGRAM is that Pup investigate
15200 the type of the task. In this case, we must see what types of concept
15300 formation there are, and how -- and when -- we decide the particular
15400 type(s) the user wants CF to handle.
15500
15600 TYPE
15700 In the dictionary, under CONCEPT:FORMATION, there is a category
15800 of facts about type. To preserve uniformity, these are structured as
15900 a set of procedural decisions. This is perhaps equivalent to a
16000 discrimination net. Each decision which must (eventually) be made is
16100 asserted as such. Effects, and when the decision must be made, are
16200 provided for most of these. The list we find is something like:
16300 (1) Concept formation can be done at one of three levels of sophistocation:
16400 (a) Classificatory
16500 (b) Comparitive
16600 (c) Metrical
16700
16800 (2) Concepts may vary with time
16900 Affected: The basic structure of forming a concept
17000
17100 (3) Concept formation may be dependent upon the speed of presentation
17200 of stimuli.
17300 Affected: Amount of effort expended on identification of stimulus.
17400
17500 (4) Instances may be left in view indefinitely or removed after processing.
17600 Affected: Whether new relations can be derived as needed, or
17700 all relations must be derived upon initial exposure to
17800 the stimulus.
17900 When: Before deciding firmly how to get relations from input stimulus.
18000
18100 (5) Logical complexity of the correct concept specification may vary,
18200 from purely conjunctive concepts to purely disjunctive concepts
18300 to mixed expressions.
18400 Affected: How we store the description of a concept.
18500
18600 (6) Positive transfer, negative transfer, neither, or both,
18700 may be present.
18800 Affected: How previous concepts learned and previous stimuli effect
18900 learning of new concept and recognition that it is new.
19000 When: Before we decide firmly how to search through our set of concepts
19100 and before we decide firmly how to insert a new concept into our
19200 set of concepts.
19300
19400 (7) Positive instances, negative instances, or both may be present.
19500 Affected: Whether to use {positive, negative} information to modify
19600 the description of a concept.
19700
19800 (8) Subject-specific behavior may be required.
19900 Affected: Parameters describing an individual must be read in.
20000 When: Before any processing routines are finalized.
20100 Why: Any processing routine might have to depend upon some parameters.
20200
20300 (9) Precise types of desired subject responses must be decided.
20400 Affected: Output variables, output format.
20500
20600 end of TYPE
20700
20800 Co-requisite with the writing of the program, a new context is
20900 created, and named WRITE:CF:PROGRAM.
21000 The main part of WRITE:PROGRAM begins. We repeatedly do: pick the best
21100 function from {OBTAIN:USABLE:INFORMATION, ADAPT:PRECONCEIVED:FUNCTION,
21200 USE:INFORMATION, FILL:IN:UNDEFINED:SECTION, CLARIFY:IMPROBABLE:SITUATION,
21300 FIX:INCORRECT:PIECE} and execute it. Repeatedly means `until done'
21400 which in this case means until the assertion (COMPLETED CF) exists.
21500 The heart of `repeatedly' is just a loop continually calling CHOOSE:FROM.
21600
21700 REPEATEDLY
21800 (CHOOSE:FROM)
21900 In our current situation, usable new information is present. We
22000 have no need for more of it yet, and we have no undefined, improbable,
22100 or incorrect pieces of code, since no code has even been generated yet.
22200 So our choice is easy.
22300
22400 USE:INFORMATION
22500 Again, this function merely chooses the best function from a set
22600 and then executes it. In this case the possibilities are {DECOMPOSE,
22700 DEFER:TASK, DEFER:DECISION, CHOOSE:DATA:STRUCTURE, MODIFY:DICTIONARY,
22800 CHOOSE:ALGORITHM, ENCODE, COMMENT}. Each will be used eventually, so
22900 don't worry now about all of them.
23000
23100 CHOOSE:FROM
23200 Pup is happiest about deferring decisions and tasks,
23300 and it finds several decisions exist already. The way is clear.
23400
23500 DEFER:DECISION
23600 As a precondition, Pup must have some knowledge of when we must
23700 next reinvestigate this decision. Some of the decisions which were
23800 set up by deciding that the task was CONCEPT:FORMATION have explicit
23900 information regarding when they must be made. Most of the decisions'
24000 when parts can be trivially obtained by prefacing the Affected part
24100 by the word "BEFORE", and following it by the words "IS FIRMLY DECIDED".
24200 The remainder of the decisions require some use of programming knowledge
24300 and concept formation knowledge to decide when they can be deferred to.
24400 When a decision can no longer be deferred (either because it actually
24500 must be made now, or because the system isn't smart enough to figure out
24600 how long it can put it off) the decision is actually made. This will
24700 usually require asking the user, but sometimes knowledge gleaned in the
24800 preceding activity will settle the decision. This is the whole motivation
24900 for trying to defer a decision as long as possible.
25000 Okay; now we get down to details. Suppose this call to DEFER:DECISION
25100 we are trying to stall decision (1), that is, whether the level of
25200 concept formation is classificatory, comparitive, or metrical.
25300 No when part is provided; in fact, no affected part is provided.
25400 At this point, the prerequisite of DEFER:DECISION sets up the subgoal
25500 that Pup find out when (that is, in what situation) it must next
25600 reinvestigate this decision.
25700
25800 WHEN:NEXT
25900 A prerequisite of knowing when next to worry about the decision
26000 is to understand the effects of (the alternatives of) the decision.
26100 In our case, we identify the alternatives as the three levels. Each of
26200 these is a separate entry in our dictionary, hence a known function.
26300 Understanding the effects means retrieving the effects part of each.
26400 For CLASSIFICATORY:CONCEPT:FORMATION this is something like
26500 "partition a domain".
26600 For COMPARITIVE:CONCEPT:FORMATION this is like
26700 "partition a domain, then linearly order the equivalence classes".
26800 For METRICAL:CONCEPT:FORMATION this is something like
26900 "partition a domain, then linearly order the equivalence classes,
27000 then define a meaningful way of joining elements of the domain,
27100 then determine an absolute scale on the domain that satisfies:
27200 the scale values of two elements is equal iff they are in the same
27300 class; the scale value of one element is less than the scale
27400 value of a second iff the class of the first is less than the class
27500 of the second according to the linear ordering of classes; the
27600 scale value of the join of two elements equals the sum of the scale
27700 values of the two elements".
27800
27900 Now that Pup understands the effects of the alternatives, it begins
28000 to execute WHEN:NEXT proper. This is merely a call to use programming
28100 knowledge about decision-deferring, applied to the effects, to determine
28200 the situation when Pup must differentiate between the alternatives.
28300
28400 One piece of programming knowledge says that "if we must decide
28500 between alternatives in set X, then we may defer the decision until
28600 after accomplishing (SETINTERSECTION (MAPCAR X PROCEDURE)), that is,
28700 until after we have done the things that must be done regardless of
28800 the outcome of the decision.
28900 In our case, we find we can apply this bit of knowledge; it tells us
29000 to first get "partition a domain" completed, then worry about what
29100 level CF must handle. We examine the piece of advice more extensively
29200 now, and see it has a suggestion: code the current task now, with
29300 the set-intersection as one subfunction call. Later, other parts
29400 of the set-union of the effects may have to be added, and we can make
29500 a note of that right now.
29600 Pup thus gets the next situation to worry about level: when
29700 (partition a domain) has been completed.
29800 end of WHEN:NEXT
29900
30000 We now execute the main part of DEFER:DECISION, which is to
30100 demonize that situation. We assume that demonizing is primitive.
30200 end of DEFER:DECISION
30300
30400 end of CHOOSE:FROM
30500
30600 As a post-requisite, USE:INFORMATION wants the user to be aware that
30700 it has actually made use of what he has told it.
30800
30900 MESSAGE
31000 Prints something like "Pup: Thank you. Acting on the information
31100 that you supplied and the information I already had about that subject,
31200 I have succesfully deferred a decision until later."
31300 end of MESSAGE
31400
31500 end of USE:INFORMATION
31600
31700 A check is now done, by REPEATEDLY(CHOOSE:FROM), to determine whether
31800 we have completed our task, the writing of CF. We haven't, so it
31900 again chooses a function to execute from {OBTAIN:USABLE:INFORMATION,
32000 FILL:IN:UNDEFINED:SECTION, USE:INFORMATION, ADAPT:PRECONCEIVED:FUNCTION,
32100 CLARIFY:IMPROBABLE:SITUATION, FIX:INCORRECT:PIECE}. The choice is
32200 made almost identically to before.
32300
32400 USE:INFORMATION
32500 As before, we must choose between various ways of using the
32600 information we have: by decomposing it into sub-tasks, by deferring
32700 a task or a decision, by choosing an algorithm or data structure,
32800 by encoding a part of the task, by modifying or adding to the dictionary,
32900 or by commenting part of the code.
33000
33100 CHOOSE:FROM
33200 As before, we like to defer, so we do.
33300
33400 DEFER:DECISION
33500 Say this call to DEFER:DECISION is working on decision (2)
33600 above. That is, whether or not the concepts may vary with time.
33700
33800 WHEN:NEXT
33900 Since we are given what is affected, we simply note that
34000 the situation to watch for is "Before the basic structure of forming a
34100 concept is firmly decided".
34200 end of WHEN:NEXT
34300
34400 We now demonize this situation. If it is encountered, we will
34500 try to resolve the decision with the then-exisiting information. Failing
34600 this, we would ask the user to decide.
34700 end of DEFER:DECISION
34800
34900 end of CHOOSE:FROM
35000
35100 MESSAGE
35200 Informs user that another decision has been deferred.
35300 end of MESSAGE
35400
35500 end of USE:INFORMATION
35600
35700 Again REPEATEDLY checks to see if CF is completed. It isn't.
35800 So we continue by choosing again. As before, we have information to use.
35900
36000 USE:INFORMATION
36100
36200 CHOOSE:FROM
36300
36400 DEFER:DECISION
36500 Suppose decision (3) is being considered now.
36600
36700 WHEN:NEXT
36800 Programming knowledge tells us that (i) (the amount of
36900 effort expended on X) is just a detail of X, and (ii) we may defer worrying
37000 about (one detail of X) until we are trying to firmly decide the
37100 details of X. This somewhat trivial reasoning yields, in our case,
37200 that we can defer the decision until "Before the details of identification
37300 of stmulus are firmly decided on".
37400 end of WHEN:NEXT
37500
37600 We demonize this situation.
37700 end of DEFER:DECISION
37800
37900 end of CHOOSE:FROM
38000
38100 MESSAGE
38200 Again reports decision deferral.
38300 end of MESSAGE
38400
38500 end of USE:INFORMATION
38600
38700 Again REPEATEDLY(CHOOSE:FROM) sees we aren't done CF.
38800
38900 USE:INFORMATION
39000
39100 CHOOSE:FROM
39200
39300 DEFER:DECISION
39400 Say we're now on decision (4). Since the when part is given,
39500 we don't have to call on WHEN:NEXT this time. We merely demonize the
39600 situation "Before deciding firmly how to get relations from input stimulus"
39700 end of DEFER:DECISION
39800
39900 end of CHOOSE:FROM
40000
40100 MESSAGE
40200 Inform user of decision deferral.
40300 end of MESSAGE
40400
40500 end of USE:INFORMATION
40600
40700 Of course, we aren't finished CF.
40800
40900 USE:INFORMATION
41000
41100 CHOOSE:FROM
41200
41300 DEFER:DECISION
41400 We're up to decision (5), the logical complexity of a concept.
41500
41600 WHEN:NEXT
41700 We transform the given Affect part, and get the situation
41800 "Before firmly deciding how we store the description of a concept".
41900 end of WHEN:NENXT
42000
42100 We demonize this situation.
42200 end of DEFER:DECISION
42300
42400 end of CHOOSE:FROM
42500
42600 MESSAGE
42700 Report decision deferral.
42800 end of MESSAGE
42900
43000 end of USE:INFORMATION
43100
43200 Still not done, so REPEATEDLY plows on.
43300
43400 USE:INFORMATION
43500
43600 CHOOSE:FROM
43700
43800 DEFER:DECISION
43900 Say we are up to decision (6), transfer effects. The when part
44000 is provided, so we merely demonize it. Notice that as soon as we try to
44100 fill in almost any part of CF, this demon will be activated.
44200 end of DEFER:DECISION
44300
44400 end of CHOOSE:FROM
44500
44600 MESSAGE
44700 end of MESSAGE
44800
44900 end of USE:INFORMATION
45000
45100 Again, REPEATEDLY goes onward.
45200
45300 USE:INFORMATION
45400
45500 CHOOSE:FROM
45600
45700 DEFER:DECISION
45800 We are up to decision (7), presence of positive/negative
45900 information being the issue here.
46000
46100 WHEN:NEXT
46200 Manipulates Affected part to get the situation "Before
46300 firmly deciding whether to use {positive,negative} information to
46400 modify the description of a concept". Also, using programming knowledge
46500 similar to that used for decision (3), we find the situation "Before
46600 firmly deciding how to modify the description of a concept".
46700 end of WHEN:NEXT
46800
46900 We demonize these situations.
47000 end of DEFER:DECISION
47100
47200 end of CHOOSE:FROM
47300
47400 MESSAGE
47500 end of MESSAGE
47600
47700 end of USE:INFORMATION
47800
47900 The REPEATEDLY function continues on.
48000
48100 USE:INFORMATION
48200
48300 CHOOSE:FROM
48400
48500 DEFER:DECISION
48600 We are up to decision (8), subject-specific behavior.
48700 Since the when part is supplied, we merely demonize it.
48800 end of DEFER:DECISION
48900
49000 end of CHOOSE:FROM
49100
49200 MESSAGE
49300 end of MESSAGE
49400
49500 end of USE:INFORMATION
49600
49700 Since CF is not completed, REPEATEDLY(CHOOSE:FROM) again must
49800 select a function and execute it.
49900
50000 USE:INFORMATION
50100
50200 CHOOSE:FROM
50300
50400 DEFER:DECISION
50500 Say we are considering decision (9), subject outputs.
50600
50700 WHEN:NEXT
50800 Two situation to return is gotten from the Affect part
50900 immediately: "Before firmly deciding output variables",
51000 "Before firmly deciding output formats".
51100 When we apply our programming knowledge, we see that output details
51200 can usually be deferred until the end of the task. So we add the
51300 situation "After the rest of the CF program is completed".
51400 end of WHEN:NEXT
51500
51600 We demonize these three situations.
51700 end of DEFER:DECISION
51800
51900 end of CHOOSE:FROM
52000
52100 MESSAGE
52200 end of MESSAGE
52300
52400 end of USE:INFORMATION
52500
52600 We still aren't finished CF, so REPEATEDLY(CHOOSE:FROM) goes on.
52700 This time, although no decisions left undeferred, we still have the
52800 usable piece of information "code CF now, with (partition a domain)
52900 as one subfunction call." Thus we don't need to obtain new information
53000 at this time, we don't need to examine or modify already existing code
53100 (since there is none yet!) so again REPEATEDLY chooses to use the
53200 information it has.
53300
53400 USE:INFORMATION
53500 Again a choice is made between decomposing, deferring,
53600 choosing a data structure or algorithm, modifying the dictionary,
53700 encoding, or commenting.
53800
53900 CHOOSE:FROM
54000 Each function's when part is examined, and the current usable
54100 information forces the choice to be encode CF.
54200
54300 ENCODE
54400 The pre-condition of encoding is, quite naturally, that the
54500 piece be codable. This is trivially true in our case.
54600 As a corequisite, a new context called ENCODING:CF is created.
54700 The first thing ENCODE does is to locate where in the existing code
54800 the new code will be inserted. Again, since no code exists, this is
54900 a vacuous task. Next, ENCODE schematically encodes the piece. This
55000 is like planning, structured programming, schemata-invocation, etc.
55100 Basically it says, since Pup supposedly knows what it is to do, it can
55200 immediately lay out how it is going to code it. In our case, the schema
55300 used is (DEFINEQ (←fn1 (LAMBDA ←arglist ←subfunction1 ←subfunction2 ...
55400 ←subfunctionN)), where we know that fn1 should be instantiated as CF,
55500 and one of the subfunctions should become the name of a function which
55600 does (partition a domain). Since no more definite knowledge about CF
55700 is known, we decide on the schematic code:
55800 (DEFINEQ (CF (LAMBDA NIL (partition a domain))))
55900 At this point, we cannot fill in any more local variable names; none
56000 exist for the task of partitioning a domain. So we invoke GET:NAME
56100 of the task (partition a domain).
56200
56300 GET:NAME
56400
56500 PLAUSIBLE:NAMES
56600 We generate the set of possible names {P, PAD, PARTITION,
56700 PARTITION:A:DOMAIN} and must eliminate PARTITION since it is in the
56800 dictionary already, and P because it is a known constant.
56900 end of PLAUSIBLE:NAMES
57000
57100 MESSAGE
57200 "The plausible names for the task (partition a domain)
57300 are PAD and PARTITION:A:DOMAIN. What does user wish to call the task?"
57400 end of MESSAGE
57500
57600 Now GET:NAME reads the user's reply. Say he types back
57700 "PARTITION:A:DOMAIN". We then assert that this is the name of the
57800 task, and that Pup and user may each refer to it by this name.
57900 end of GET:NAME
58000
58100 Now we can replace (partition a domain) by the function call
58200 (PARTITION:A:DOMAIN) in the schema. This is now both asserted and evaled.
58300 Finally, the postrequisite of ENCODE is to apply COMMENT if it is
58400 relevant. So we examine the when part of comment, and see that it is
58500 relevant since a piece of code exists but is uncommented.
58600
58700 COMMENT
58800 The precondition is to know some comment-like information
58900 about the piece o code involved. In our case, we find that we have
59000 the piece of usable knowledge "Later, other elements of
59100 {(linearly order the classes), (define a meaningful join function)
59200 (define an absolute scale)} may be added to the code for CF".
59300 Thus satiated, we can begin COMMENT proper, which merely commands us
59400 to associate this information with the piece of code. In this way,
59500 if one of these tasks is ever actually called for, we will know where
59600 it belongs in the system we are writing.
59700 end of COMMENT
59800
59900 end of ENCODE
60000
60100 end of CHOOSE:FROM
60200
60300 MESSAGE
60400 Informs user that we encoded (part of) the function CF.
60500 end of MESSAGE
60600
60700 end of USE:INFORMATION
60800
00100
00200 We are now back in the REPEATEDLY(CHOOSE:FROM) loop of WRITE:PROGRAM.
00300 We have used up all the usable information we had, so USE:INFORMATION won't
00400 be chosen. We haven't noticed any improbable or incorrect pieces of code,
00500 so neither of those functions will be called now. If we have to, we can
00600 call OBTAIN:USABLE:INFORMATION, but that isn't necessary here. We have an
00700 ideal situation for FILL:IN:UNDEFINED:SECTION, according to its when part.
00800
00900 FILL:IN:UNDEFINED:SECTION
01000 First we check that no new information exists. It doesn't.
01100 Next we must select the undefined section we want to work on.
01200
01300 CHOOSE
01400 This is similar to CHOOSE:FROM, but here we don't have an explicit
01500 list of alternatives. We repeatedly generate an alternative and compare
01600 it to the best one we've found so far.
01700
01800 REPEATEDLY
01900
02000 GENERATE
02100 Basically, we are generating the setintersection of
02200 {pieces of code} {undefined things}. Programming knowledge tells us
02300 the best way is to pick the smaller set, go through it and check to see
02400 if an element is also in the bigger set. We also know that the set
02500 of undefined things is bigger than any other set. So we pick an element
02600 from the set of pieces of code, say CF, and tag it. It isn't in
02700 the set of undefined things, since it is defined. We pick another
02800 piece of code, PARTITION:A:DOMAIN. It is undefined. We return this.
02900 end of GENERATE
03000
03100 COMPARE
03200 We compare the current element with the best so far.
03300 Since this is the first element generated, this test is vacuous.
03400 end of COMPARE
03500
03600 The repeatedly loop will continue until GENERATE fails.
03700
03800 GENERATE
03900 There are no untagged elements in {pieces of code}. So
04000 GENERATE unntags all of them, and then reports failure.
04100 end of GENERATE
04200
04300 Thus REPEATEDLY returns the best choice: PARTITION:A:DOMAIN.
04400 end of REPEATEDLY
04500
04600 end of CHOOSE
04700
04800 We continue FILL:IN:UNDEFINED:SECTION by asserting that Pup is
04900 about to firmly decide how to do PARTITION:A:DOMAIN. This triggers
05000 the subject-specific behavior demon (decision 8).
05100
05200 OBEY:DEMON (RESOLVE:DECISION)
05300 This is automatically enetered at this time. First, we see if we
05400 have already answered this question inadvertantly. Next, we see if any
05500 relevant information has been gleaned pertaining to this decision.
05600 In our case, both attempts draw blanks. Thus we cannot postpone
05700 bothering the user any longer, so we ask him directly.
05800
05900 MESSAGE
06000 "Pup: Sorry to bother you, user, but I can't wait any longer
06100 to ask you this: Is subject-specific behavior required. The effect
06200 would be to require subject-specific parameters to be read in.
06300 An and all processing routines might depend upon some of these parameters.
06400 In particular, PARTITION:A:DOMAIN, the function I am currently working
06500 on, might depend on some subject-specific parameters."
06600 end of MESSAGE
06700
06800 Suppose the user types "No, subject-specific behavior will not be
06900 required". This means that the decision can be ignored, and its
07000 demon can be murdered. Control passes back to the point where it was
07100 interrupted.
07200 end of OBEY:DEMON (RESOLVE:DECISION)
07300
07400 Undaunted, FILL:IN:UNDEFINED:SECTION again starts to fill in
07500 PARTITION:A:DOMAIN. First it examines what it knows about this.
07600 It knows "partition a domain", but this is not usable yet. It
07700 sets up the precondition of having usable information about this
07800 function. To do this, the only function applicable is
07900 OBTAIN:USABLE:INFORMATION. This function must now be called.
08000
08100 OBTAIN:USABLE:INFORMATION
08200 We must choose from among translating, getting entirely new
08300 information, analyzing the implications of current information, or
08400 extracting a relevant subset from a large set of information.
08500
08600 CHOOSE:FROM
08700 Of all these functions, we can see by their when parts that only
08800 the first two are applicable, and we don't like bothering the user, so we
08900 try to translate what we know about the function.
09000
09100 TRANSLATE
09200 We must understand what (partition a domain) means.
09300
09400 PARSE
09500 Eventually we break this up as (partition)(a domain).
09600 In looking up partition, we find that it actually takes one argument.
09700 The LOOKUP of (a domain) says to replace it by "set". Thus the final
09800 parse is (PARTITION SET).
09900 end of PARSE
10000
10100 Since this is usable, we are finished translating.
10200 end of TRANSLATE
10300
10400 end of CHOOSE:FROM
10500
10600 MESSAGE
10700 Informs user that we have translated a piece of information.
10800 end of MESSAGE
10900
11000 end of OBTAIN:USABLE:INFORMATION
11100
11200 Now we continue FILL:IN:UNDEFINED:SECTION. This is actually structured
11300 similarly to WRITE:PROGRAM, in that we choose from the same set of
11400 functions to try. Now that our task is executable, we investigate its
11500 type. This should help us decide how to code it.
11600
11700 TYPE
11800 The list of decisions we find is something like the following:
11900 (10) Partition can be strict partition or weak partition.
12000 Affected: Whether one element can belong to two different classes,
12100 and whether an element can belong to no class at all.
12200 When: Before firmly deciding termination of identification process.
12300
12400 (11) Partition can be built up in three ways:
12500 (a) Given an element, determine which class it belongs to.
12600 Repeat this for each element of the domain.
12700 (b) Given a class, determine which elements it contains.
12800 Repeat this for each class of the partition.
12900 (c) Take in pairs of (element name, class containing this element).
13000 Repeat for each possible different pair.
13100 Affected: How partitioning is done.
13200 I have numbered these two decisions ten and eleven to preserve the
13300 ability to globally refer to the Nth decision encountered.
13400 end of TYPE
13500
13600 We now enter into a REPEATEDLY loop, and continue until code for
13700 PARTITION:A:DOMAIN exists.
13800
13900 REPEATEDLY
14000 As before, we must choose from obtaining usable information,
14100 using current information, filling in an undefined section, investi-
14200 gating an improbable situation, or correcting a bug. Since our probing
14300 of the types of partitions has generated some new information, we
14400 evaluate USE:INFORMATION to be our smartest direction toward progress.
14500
14600 USE:INFORMATION
14700 A choice is made between decomposing, deferring, choosing a
14800 data structure or algorithm, modifying the dictionary, encoding,
14900 or commenting.
15000
15100 CHOOSE:FROM
15200 We now have more new decisions.
15300
15400 DEFER:DECISION
15500 Say we work now on decision (10), strict or weak partitioning.
15600
15700 WHEN:NEXT
15800 In addition to the supplied situation "Before firmly
15900 deciding termination of identification process" we can add (using
16000 programming knowledge) "Before firmly deciding all of identification
16100 process" and "After deciding some of identification process".
16200 end of WHEN:NEXT
16300
16400 We demonize these situations.
16500 end of DEFER:DECISION
16600
16700 end of CHOOSE:FROM
16800
16900 MESSAGE
17000 end of MESSAGE
17100
17200 end of USE:INFORMATION
17300
17400 Back in REPEATEDLY, we check to see if code for PARTITION:A:DOMAIN
17500 exists yet. It doesn't, so we plow on.
17600
17700 USE:INFORMATION
17800
17900 CHOOSE:FROM
18000
18100 DEFER:DECISION
18200 We are on decision (11) now, how to build the partition.
18300
18400 WHEN:NEXT
18500 From the supplied Affect part, we construct the situation
18600 "Before firmly deciding how partitioning is done".
18700 end WHEN:NEXT
18800
18900 We demonize the situation.
19000 end of DEFER:DECISION
19100
19200 end of CHOOSE:FROM
19300
19400 Here we continue USE:INFORMATION. At this point, we would
19500 begin to satisfy the postrequisites. Implicitly, the first of these
19600 is a demon check. Lo and behold, the demon we've just created
19700 realizes he must act: we are already in the situation of deciding
19800 how partitioning is done!
19900
20000 OBEY:DEMON (RESOLVE:DECISION)
20100 As the last time it was called, we don't have any new information
20200 which is relevant to this decision. We must ask the user.
20300
20400 MESSAGE
20500 Prints "Pup: To partition a domain, do we (a) take in
20600 element, determine name of its class, repeat, or (b) take in class
20700 name, determine some of its elements, repeat, or (c) take in element
20800 and corresponding class name simultaneously, repeat?"
20900 end of MESSAGE
21000
21100 Let us say the user types "(a) and (c)".
21200 We now have resolved the decision, though we haven't understood the
21300 user's answer yet.
21400 end OBEY:DEMON (RESOLVE:DECISION)
21500
21600 We now execute the postrequisite of USE:INFORMATION, typing
21700 a message to the user. Notice that the recent resolving of the
21800 decision alters the message.
21900
22000 MESSAGE
22100 "Pup: Forced to resolve the decision about how to build
22200 the partition. Thank you for your help."
22300 end of MESSAGE
22400
22500 end of USE:INFORMATION
22600
22700 Back in REPEATEDLY, we still see no code for PARTITION:A:DOMAIN,
22800 so we again must choose what to do. This time, we have no more
22900 usable information, so our choice is limited.
23000
23100 OBTAIN:USABLE:INFORMATION
23200 Since new information exists, we need not GET:NEW:INFORMATION.
23300 Since the new information is not too big, we need not
23400 EXTRACT:RELEVANT:SUBSET of it. Since it isn't translated, we can't
23500 even ANALYZE:IMPLICATIONS of it. So we are left with translation.
23600
23700 TRANSLATE
23800
23900 PARSE
24000 Eventually: ((a)) (and) ((c)).
24100
24200 LOOKUP
24300 Replaces (a) by "take in element, determine name of its
24400 class, repeat". Again, this is not yet understood, but Pup is progressing.
24500 end LOOKUP
24600
24700 LOOKUP
24800 Replaces the infix "and" by the known prefix function AND.
24900 end of LOOKUP
25000
25100 LOOKUP
25200 Replaces (c) by "take in element and corresponding class
25300 name simultaneously, repeat".
25400 end of LOOKUP
25500
25600 The TRANSLATE function continues by seeing whether or not
25700 to apply EXTRACT:RELEVANT:SUBSET. Since the amount of information
25800 is relatively small, it decides not to. Next it sees whether or not
25900 the translation is completely usable. But (AND "take in element,
26000 determine name of its class, repeat" "take in element and corresponding
26100 class name simultaneously, repeat") contains nonusable parts. So
26200 TRANSLATE calls itself recursively on each such part.
26300
26400 TRANSLATE
26500
26600 PARSE
26700 Eventually breaks it up as (take in) (element)
26800 (,) (determine name of its class) (,) (repeat)
26900
27000 LOOKUP
27100 "take in" is known as the function INPUT. It takes
27200 one argument, so the next piece is automatically accepted.
27300 end of LOOKUP
27400
27500 LOOKUP
27600 the comma indicates the function SERIES is being
27700 implicitly used here. It is a prefix function, and its arguments
27800 are separated by commas.
27900 end of LOOKUP
28000
28100 LOOKUP
28200 "determine name of its class" is recognized, via determine,
28300 as a function (as yet unknown) whose purpose is to get "name of
28400 its class", whatever that is. We don't worry about what it is, since
28500 our knowledge of determine tells us it is an entity we can later get.
28600 end of LOOKUP
28700
28800 LOOKUP
28900 "repeat" means that the toplevel function, SERIES,
29000 calls itself at this point. A flag for IMPROBABLE:SITUATION is
29100 set, since no way to break out of the recursion is given yet.
29200 end of LOOKUP
29300
29400 Translated, we have something like the following:
29500 (SERIES (INPUT element) (DETERMINE name:of:its:class) (RECURSE
29600 SERIES)). Since all the functions understood, we shan't recurse
29700 again. However, some of them are not yet definitely named. The
29800 proper demonizing is done so that they will eventually be noticed.
29900 end of TRANSLATE
30000
30100 TRANSLATE
30200 Now we work on the second argument. After similar parsing,
30300 looking up, looking up,... we arrive at the translation:
30400 (SERIES (SIMULTANEOUSLY (INPUT element) (INPUT corresponding:class:name))
30500 (RECURSE SERIES)). Again, we don't recurse on translation any more.
30600 Note that here all the functions used are known to the system already.
30700 end of TRANSLATE
30800
30900 end of TRANSLATE
31000
31100 We are back in OBTAIN:USABLE:INFORMATION, and we have succeeded.
31200 end OBTAIN:USABLE:INFORMATION
31300
31400 Back in REPEATEDLY, no code for the partitioning has shown up
31500 yet, so we must choose again. This time, though, usable information
31600 exists.
31700
31800 USE:INFORMATION
31900 We can use the information in one of several ways.
32000
32100 CHOOSE:FROM
32200 Keeping in mind our current subgoal, that of solving
32300 the PARTITION:A:DOMAIN programming problem, we try to encode what
32400 we have learned. Unfortunately, it is not yet codable, since we
32500 haven't decided on any algorithm. The function AND is not an immediately
32600 codable function: it means "provide capabilities to handle all the
32700 following". It does NOT mean "simultaneously..." or "in a series...".
32800 There are known functions for each of these other tasks. In any event,
32900 CHOOSE:FROM must select another function which will lead to codability.
33000 The best suited seems to be the one that will transform the declarative
33100 function AND into a codable procedural type of function.
33200
33300 CHOOSE:ALGORITHM
33400 We analyze the details of AND, and discover that one way
33500 it is sometimes realized is as follows: to get (AND x y), if
33600 y is a sublist of x, then we may insert a conditional into each
33700 point of x which is not in y, diverting flow around this if we are in
33800 situation y, and passing us through if we are in situation x.
33900 (Here, y is a sublist of x means each step appearing in y appears
34000 in x, and if s1 appears before s2 in y, then it also does in x.)
34100 After some transformations, mostly logical in character, at the level
34200 of QA3 or below, we arrive at the new form for the knowledge:
34300 (SERIES (INPUT element) (COND (situation:difference (INPUT
34400 corresponding:class:name)) (T (DETERMINE name:of:its:class)))
34500 (RECURSE SERIES)).
34600 end of CHOOSE:ALGORITHM
34700
34800 end of CHOOSE:FROM
34900
35000 MESSAGE
35100 Informs user that algorithm has been chosen.
35200 end of MESSAGE
35300
35400 end of USE:INFORMATION
35500
35600 Back in REPEATEDLY. Code isn't there yet. We choose again.
35700
35800 USE:INFORMATION
35900
36000 CHOOSE:FROM
36100 Now the information contains no functions known to be
36200 non-codable, and we expect that ti shall be codable. The piece of
36300 programming knowledge implicit here is that unless you know that a
36400 function should be worked on before making an actual name of it
36500 and inserting it as a subfunction somewhere, you can probably go
36600 ahead and do it, and then later define or redefine this function,
36700 without having to disturb any of its invocators. That may sound
36800 confusing, but if you concretize it at all you will see what it
36900 is saying.
37000
37100 ENCODE
37200 As a co-requisite, a new context is created.
37300 First we locate the point of insertion. This is relatively
37400 trivial: by bookkeeping, we find that this is the definition
37500 of PARTITION:A:DOMAIN. As we discover this, a few assertions
37600 relevant to self-reference are made. ENCODE now schematically
37700 builds up the code:
37800 (DEFINEQ (←fn (LAMBDA ←arglist ←subfn1 ... ←subfnN)) is used, becoming
37900 (DEFINEQ (PARTITION:A:DOMAIN (LAMBDA NIL (INPUT element)
38000 (COND (situation:difference (INPUT corresponding:class:name))
38100 (T (DETERMINE name:of:its:class)))
38200 (PARTITION:A:DOMAIN) ]
38300 Here notice that RECURSE is the type of function which instantiates
38400 into a forced evaluation, and that this evaluation draws on the
38500 awareness that series is self, and that self is PARTITION:A:DOMAIN.
38600 We have eliminated explicit mention of SERIES because our
38700 schema tells us that we may simply drop that functionn call.
38800 Thus the schema implicitly has the programming knowledge that
38900 programs -- in particular LISP function -- are executed
39000 sequentially by default. As a first pass, our system may be
39100 slightly dumber and turn out
39200 (DEFINEQ (PARTITION:A:DOMAIN (LAMBDA NIL (PROG NIL
39300 START:OF:SERIES (INPUT element)
39400 (COND (situation:difference
39500 (INPUT corresponding:class:name))
39600 (T
39700 (DETERMINE name:of:its:class)))
39800 (GO START:OF:SERIES) ]
39900 This is no big deal, and merely reflects the sophistocation of the
40000 system, not its abilities.
40100 At any rate, we continue substituting local variables in, and
40200 see we must get names for situation:difference, element,
40300 corresponding:class:name, name:of:its:class.
40400
40500 GET:NAME
40600
40700 PLAUSIBLE:NAMES
40800 Generates {SD, S, SITUATION:DIFFERENCE,
40900 SITUATION}. None are eliminated.
41000 end of PLAUSIBLE:NAMES
41100
41200 MESSAGE
41300 "The plausible names for the task
41400 (situation:difference (a) (b)) are SD, S, SITUATION:DIFFERENCE,
41500 and SITUATION. What does the user wish to call the task?"
41600 end of MESSAGE
41700
41800 Say user types "(HAS:NAME ELEMENT)". This is actually much
41900 more meaningful to human users, and in fact will be used in a nontrivial
42000 way by Pup later on.
42100 end of GET:NAME
42200
42300 GET:NAME
42400
42500 PLAUSIBLE:NAMES
42600 Gets {E, ELEMENT}.
42700 end of PLAUSIBLE:NAMES
42800
42900 MESSAGE
43000 end of MESSAGE
43100
43200 Say user types back "ELEMENT".
43300 end of GET:NAME
43400
43500 GET:NAME
43600
43700 PLAUSIBLE:NAMES
43800 Get set {CORRESPONDING:CLASS:NAME, CCN,
43900 CLASS:NAME, THE:CLASS:NAME, CN, ITS:CLASS:NAME, CORRESPONDING:SET:NAME,
44000 CORRESPONDING:CLASS, C, CORRESPONDING}. C is eliminated.
44100 end of PLAUSIBLE:NAMES
44200
44300 MESSAGE
44400 end of MESSAGE
44500
44600 Say user types back "CLASS:NAME".
44700 end of GET:NAME
44800
44900 GET:NAME
45000
45100 PLAUSIBLE:NAMES
45200 {NAME:OF:ITS:CLASS, NAME, NOIC, N, NAME:CLASS,
45300 CLASS:NAME, ITS:CLASS, ITS:CLASS:NAME, CN, IC, ICN, NAME:OF:THE:CLASS,
45400 THE:CLASS:NAME, TCN, NOTC}. We can eliminate N, NOTC.
45500 Before PLAUSIBLE:NAMES returns, the fringe:of:conciousness demon
45600 is activated: he has just seen two sets, assumed to be independent,
45700 with a significant (statistically) intersection. Thus there may be
45800 some relation. This possibility bears no relation to any current task,
45900 so it is merely tucked away until either object is mentioned again.
46000 end of PLAUSIBLE:NAMES
46100
46200 MESSAGE
46300 We print out the plausible names, and the demon
46400 we just created suddenly jumps up and forces us to add the note:
46500 "By the way, I suspect that this has something to do with
46600 CLASS:NAME. So the name of this object may be CLASS:NAME or some
46700 very similar thing."
46800 end of MESSAGE
46900
47000 Say user types "CLASS:NAME". Pup then assumes that
47100 this is identical to the previous occurrence of CLASS:NAME. If
47200 Pup had not noticed the similarity earlier, it would now have
47300 either asked the user for confirmation, or else made a note of an
47400 improbable piece of coding.
47500 end of GET:NAME
47600
47700 We are back in ENCODE, and our piece of code is now
47800 fully instantiated. As before, we assert and eval it. As the
47900 postrequisite, we must comment the piece of code.
48000
48100 COMMENT
48200 Here we tack onto the code its various past stages
48300 of evolution, any side information provided about the constituent
48400 functions, the fact that we have an infinite recursion here,
48500 the names of functions and entities not yet defined. We also
48600 assert most of these things, so they can be used by the global
48700 conciousness of the system.
48800 end of COMMENT
48900
49000 end of ENCODE
49100
49200 end of CHOOSE:FROM
49300
49400 MESSAGE
49500 end of MESSAGE
49600
49700 end of USE:INFORMATION
49800
49900 Back in REPEATEDLY, we do find the assertion that code exists
50000 for PARTITION:A:DOMAIN. Thus we are done this loop:
50100 end of REPEATEDLY
50200
50300 We are back in FILL:IN:UNDEFINED:SECTION. There are no postrequisites,
50400 except of course to check all demons before we exit.
50500 end of FILL:IN:UNDEFINED:SECTION
50600
00100
00200 We are now all the way back to the REPEATEDLY loop in WRITE:PROGRAM.
00300 Alas, code for all of CF doesn't exist yet, so we must plow onward.
00400 As before, we decide to fill in one of the undefined pieces.
00500
00600 FILL:IN:UNDEFINED:SECTION
00700
00800 CHOOSE
00900
01000 REPEATEDLY
01100
01200 GENERATE
01300 Produces ELEMENT.
01400 end of GENERATE
01500
01600 COMPARE
01700 So far, ELEMENT is trivially the best.
01800 end of COMPARE
01900
02000 GENERATE
02100 Produces HAS:NAME
02200 end of GENERATE
02300
02400 COMPARE
02500 Since the invocation of HAS:NAME involves ELEMENT, we
02600 still prefer to do ELEMENT first.
02700 end of COMPARE
02800
02900 GENERATE
03000 Produces CLASS:NAME
03100 end of GENERATE
03200
03300 COMPARE
03400 Element is mentioned before Classname in a Series; this
03500 is strong evidence that we should work on it first. Also, we have
03600 seen two reasons for working on element, and only one for classname.
03700 end of COMPARE
03800
03900 GENERATE
04000 Fails.
04100 end of GENERATE
04200
04300 Thus REPEATEDLY returns the entity ELEMENT as the best bet.
04400 end of REPEATEDLY
04500
04600 end of CHOOSE
04700
04800 We continue FILL:IN:UNDEFINED:SECTION by asserting that we are
04900 going to investigate ELEMENT. The decision (2) demon reacts to this.
05000
05100 OBEY:DEMON (RESOLVE:DECISION)
05200 We must decide whether or not the concepts can vary with time.
05300 This will affect the structure of ELEMENT, a typical concept.
05400
05500 MESSAGE
05600 Asks the user this question.
05700 end of MESSAGE
05800
05900 Say user replies negatively. That is, concepts are time invariant.
06000 Thus nothing special need be done now. We proceed.
06100 end of OBEY:DEMON (RESOLVE:DECISION)
06200
06300 Now we investigate the few facts we have about ELEMENT.
06400 From earlier, we have assertions that ELEMENT is a member of DOMAIN,
06500 and DOMAIN is a set whose subsets are CONCEPTS and whose elements
06600 are INSTANCES of CONCEPTS. This is insufficient to characterize ELEMENT.
06700
06800 REPEATEDLY
06900 This REPEATEDLY loop continues until ELEMENT is defined: via
07000 code, data structure, formally in terms of other entities, etc. Until
07100 then we choose appropriate functions from {OBTAIN:USABLE:INFORMATION,
07200 USE:INFORMATION, FILL:IN:UNDEFINED:SECTION, CLARIFY:IMPROBABLE:SITUATION,
07300 FIX:INCORRECT:PIECE}. None of the information about ELEMENT is usable
07400 at this time.
07500
07600 OBTAIN:USABLE:INFORMATION
07700
07800 CHOOSE:FROM
07900 Nothing exists to be translated, what we know is too small to
08000 be worthwhile trying to extract what is relevant.
08100
08200 GET:NEW:INFORMATION
08300 Pup must satisfy the prerequisite, that it knows the
08400 specifics of what it wants.
08500
08600 SPECIFICS
08700
08800 REASON:TO:GET
08900 Here we observe that ELEMENT is probably an instance
09000 of a CONCEPT. In concept-formation studies, an instance of a concept is
09100 typically an object with some structure along various dimensions. From
09200 programmer-user interface knowledge, we know that what we need is thus
09300 a description of the structure of an ELEMENT.
09400 end of REASON:TO:GET
09500
09600 end of SPECIFICS
09700
09800 We now continue with the main section of GET:NEW:INFORMATION.
09900 This merely queries the user and accepts his reply.
10000
10100 MESSAGE
10200 "Pup: I want a description of the structure of an
10300 ELEMENT. I presume that an ELEMENT is an instance of a concept."
10400 end of MESSAGE
10500
10600 Pup reads the reply. Say the user types "An element
10700 is a description of a static scene".
10800 end of GET:NEW:INFORMATION
10900
11000 end of CHOOSE:FROM
11100
11200 MESSAGE
11300 end of MESSAGE
11400
11500 end of OBTAIN:USABLE:INFORMATION
11600
11700 We continue on in the REPEATEDLY loop.
11800
11900 OBTAIN:USABLE:INFORMATION
12000
12100 CHOOSE:FROM
12200
12300 TRANSLATE
12400
12500 REPEATEDLY
12600
12700 PARSE
12800 Eventually ((An element) is ((a description of) (a static
12900 scene))).
13000 end of PARSE
13100
13200 LOOKUP
13300 (An element) becomes ELEMENT.
13400 end of LOOKUP
13500
13600 LOOKUP
13700 (is) becomes EQUAL
13800 end of LOOKUP
13900
14000 LOOKUP
14100 (A description of) becomes DETAILS, with the note that
14200 the details are relevant, written, and pertain to the next parsed object.
14300 Thus (a static scene) is not worked on yet.
14400 end of LOOKUP
14500
14600 end of TRANSLATE
14700
14800 end of CHOOSE:FROM
14900
15000 MESSAGE
15100 end of MESSAGE
15200
15300 end of OBTAIN:USABLE:INFORMATION
15400
15500 We continue on in the REPEATEDLY loop.
15600
15700 USE:INFORMATION
15800
15900 CHOOSE:FROM
16000 Since the information was in response to a "What is X?"
16100 question, and is of the form "(EQUAL X Y)", we assume that what we are
16200 being told is actually that the definition of X is Y. Thus the best suited
16300 function is one which concerns how things are defined.
16400
16500 MODIFY:DICTIONARY
16600 We add to the facts about ELEMENT that it is currently
16700 defined as (DETAILS a:static:scene), with associated comments about the
16800 use of DETAILS (as we discussed above). For this to be a valid definition,
16900 there must be knowledge of its parts already in existence. But this is
17000 not true for a:static:scene. So we must understand this piece also.
17100
17200 OBTAIN:USABLE:INFORMATION
17300
17400 CHOOSE:FROM
17500
17600 TRANSLATE
17700
17800 PARSE
17900 (a) (static) (scene)
18000 end of PARSE
18100
18200 LOOKUP
18300 (a) becomes an adjectival note: we ae referring to
18400 a singular, specific entity.
18500 end of LOOKUP
18600
18700 LOOKUP
18800 (static) becomes an adjectival note also:
18900 ignore dynamic qualities of the entity.
19000 end of LOOKUP
19100
19200 LOOKUP
19300 (scene) is recognized as a first-order, one-sorted
19400 mathematical structure, with underlying set O of objects, and associated
19500 sets R of static relations about objects, and D of dymnamic relations
19600 about objects. SCENE is in fact a known block(=being = entity = function).
19700 end of LOOKUP
19800
19900 end of TRANSLATE
20000
20100 end of CHOOSE:FROM
20200
20300 end of OBTAIN:USABLE:INFORMATION
20400
20500 So the modification procedure now knows enough to
20600 construct an entire block about ELEMENT. It is defined as
20700 (DETAILS STATIC:SCENE), and STATIC:SCENE is defined as (ALL:BUT
20800 dynamic:qualities:of SCENE)
20900 Again, we must better define STATIC:SCENE, since some parts of it
21000 aren't in the dictionary. ALL:BUT is the type of forced-evaluation
21100 function we encountered earlier.
21200
21300 ALL:BUT
21400 Here we go through the second argument's being,
21500 weeding out whatever pertains to the first argument. We see that
21600 the set D, of dynamic relations, is exactly what we must eliminate.
21700 end of ALL:BUT
21800
21900 So MODIFY:DICTIONARY revises its definition of
22000 STATIC:SCENE to be identical to that of SCENE, except the part
22100 referring to D is omitted. The dictionary is fulfilled now.
22200 end of MODIFY:DICTIONARY
22300
22400 end of CHOOSE:FROM
22500
22600 MESSAGE
22700 end of MESSAGE
22800
22900 end of USE:INFORMATION
23000
23100 Back in the REPEATEDLY loop. But we do have a sufficient
23200 definition of ELEMENT now, so we needn't worry any more about it
23300 immediately.
23400 end of REPEATEDLY
23500
23600 end of FILL:IN:UNDEFINED:SECTION
23700
23800 Again, we find ourselves back in the REPEATEDLY loop of WRITE:PROGRAM.
23900 Since CF is not yet completed, we must choose again one function to
24000 execute from {OBTAIN:USABLE:INFORMATION, USE:INFORMATION,
24100 FILL:IN:UNDEFINED:SECTION, CLARIFY:IMPROBABLE:SITUATION,
24200 FIX:INCORRECT:PIECE}.
24300
24400 FILL:IN:UNDEFINED:SECTION
24500
24600 CHOOSE
24700
24800 REPEATEDLY
24900
25000 GENERATE
25100 Produces HAS:NAME
25200 end of GENERATE
25300
25400 COMPARE
25500 So far, HAS:NAME is trivially the best choice.
25600 end of COMPARE
25700
25800 GENERATE
25900 Produces CLASS:NAME
26000 end of GENERATE
26100
26200 COMPARE
26300 Since HAS:NAME is a predicate, it is probably more complicated
26400 than, and may even involve, CLASS:NAME. Thus it gets a slightly lower spot.
26500 end of COMPARE
26600
26700 GENERATE
26800 Fails.
26900 end of GENERATE
27000
27100 end of REPEATEDLY
27200
27300 end of CHOOSE
27400
27500 We continue FILL:IN:UNDEFINED:SECTION by asserting that we are
27600 going to investigate CLASS:NAME.
27700 This turns out to be very easy, since we can trace it back to decision
27800 (11), TYPE of PARTITION process. We see it is a detail of CLASS, where
27900 CLASS is synonomous with CONCEPT. The detail is in fact NAME:OF, which
28000 is already understood; it is how Pup and User can refer to an entity.
28100 This information is asserted in various places, and we never even have
28200 to enter the REPEATEDLY loop provided for in the main body of
28300 FILL:IN:UNDEFINED:SECTION.
28400 end of FILL:IN:UNDEFINED:SECTION
28500
28600 Back in REPEATEDLY loop of WRITE:PROGRAM.
28700
28800 FILL:IN:UNDEFINED:SECTION
28900
29000 CHOOSE
29100
29200 REPEATEDLY
29300
29400 GENERATE
29500 Gives HAS:NAME
29600 end of GENERATE
29700
29800 COMPARE
29900 Trivially, picks HAS:NAME
30000 end of COMPARE
30100
30200 GENERATE
30300 fails
30400 end of GENERATE
30500
30600 end of REPEATEDLY
30700
30800 end of CHOOSE
30900
31000 We assert that we are going to fill in HAS:NAME. We know it
31100 is a predicate. That is insufficient knowledge.
31200
31300 OBTAIN:USABLE:INFORMATION
31400
31500 GET:NEW:INFORMATION
31600
31700 SPECIFICS
31800 WE know that the specifics about a predicate involve when it
31900 is true and when it is false.
32000 end of SPECIFICS
32100
32200 MESSAGE
32300 "Pup: I want to know when HAS:NAME is true and when it is
32400 false. I would like a logical statement which is equivalent to HAS:NAME
32500 if possible."
32600 end of MESSAGE
32700
32800 Say the user types "Front part of ELEMENT is not ?".
32900 end of GET:NEW:INFORMATION
33000
33100 end of OBTAIN:USABLE:INFORMATION
33200
33300 OBTAIN:USABLE:INFORMATION
33400
33500 TRANSLATE
33600
33700 PARSE
33800 (front part of) (ELEMENT) (is not) (?)
33900 end of PARSE
34000
34100 LOOKUP
34200 (front of) becomes CAR
34300 end of LOOKUP
34400
34500 LOOKUP
34600 (is not) becomes the composition of NOT with EQUAL.
34700 end of LOOKUP
34800
34900 LOOKUP
35000 (?) is recognized as a literal constant (QUOTE ?)
35100 end of LOOKUP
35200
35300 end of TRANSLATE
35400
35500 end of OBTAIN:USABLE:INFORMATION
35600
35700 USE:INFORMATION
35800 A predicate is like a function: it is defined when it is encoded.
35900
36000 ENCODE
36100 A new context is created. We schematically encode the predicate
36200 as (DEFINEQ (←pred (LAMBDA ←arglist (COND ←equivalent:pred)))), then
36300 (DEFINEQ (HAS:NAME (LAMBDA (ELEMENT)
36400 (COND ((NOT (EQUAL (CAR ELEMENT) (QUOTE ?]
36500 We have the unnecessary COND in the schema in case the equivalent:pred
36600 turns out to be not entirely equivalent.
36700
36800 COMMENT
36900 We now tack a note to this effect onto the code for HAS:NAME.
37000 We assert that this is an improbable situation; if it still remains at
37100 the end of the task, we can eliminate the COND (and one level of parens)
37200 without altering the function definition.
37300 end of COMMENT
37400
37500 We assert and eval the definition.
37600 end of ENCODE
37700
37800 end of USE:INFORMATION
37900
38000 end of FILL:IN:UNDEFINED:SECTION
00100
00200 Back in the WRITE:PROGRAM REPEATEDLY loop, we see by examing when
00300 parts that no totally undefined sections exist. We do have several
00400 calls to functions which are preconceived: that is, they are known as
00500 primitives by Pup, although their use at each point in each program
00600 may vary slightly. Thus, they must be adapted to fit the situation.
00700
00800 ADAPT:PRECONCEIVED:FUNCTION
00900 This is set up very similarly to FILL:IN:UNDEFINED:SECTION.
01000
01100 CHOOSE
01200
01300 REPEATEDLY
01400
01500 GENERATE
01600 Gives INPUT.
01700 end of GENERATE
01800
01900 COMPARE
02000 Of course, INPUT is the best so far.
02100 end of COMPARE
02200
02300 GENERATE
02400 Produces DETERMINE
02500 end of GENERATE
02600
02700 COMPARE
02800 As before, when no overriding reason exists, we will
02900 choose the easier function. This would be INPUT. In fact, a reason
03000 does exist to choose it: it precedes DETERMINE in a SERIES.
03100 end of COMPARE
03200
03300 GENERATE
03400 fails
03500 end of GENERATE
03600
03700 end of REPEATEDLY
03800
03900 end of CHOOSE
04000
04100 So INPUT is the preconceived function we are going to adapt.
04200 In particular, we are going to work on the specific use of the
04300 function in the code (INPUT ELEMENT). First, we replace INPUT
04400 by INPUT:1. Next, we examine the TYPE categories of the INPUT being.
04500 We find something like:
04600 (12) Has the object we want inputted already been obtained?
04700 Affect: Whether we use an assignment to a variable or to a read.
04800 When: Before deciding code for INPUT.
04900
05000 (13) If the object we are inputting has several parts,
05100 we may have several assignment statements after the initial one,
05200 each assignment sets the name of a part of the object to
05300 the corresponding part of the object just inputted.
05400 Affect: Code for INPUT.
05500
05600 So both decisions must be made before we can code INPUT:1.
05700
05800 OBEY:DEMON (RESOLVE:DECISION)
05900 There have been no branches in the program thus far, and nothing
06000 has yet been inputted. So we assume that ELEMENT has not already been
06100 obtained. Thus we must use an assignment to a READ.
06200 end of OBEY:DEMON (RESOLVE:DECISION)
06300
06400 OBEY:DEMON (RESOLVE:DECISION)
06500 Yes, we see that ELEMENT is composed of parts, namely it
06600 consists of (a) a specification of what objects are in the scene,
06700 (b) a specification of what static relations hold among the objects,
06800 and (c) some indication when CLASS:NAME is absent (when HAS:NAME is
06900 false.) Thus several assignments may be inserted after the initial
07000 one.
07100 end of OBEY:DEMON (RESOLVE:DECISION)
07200
07300 Now we shall try to code INPUT:1.
07400
07500 ENCODE
07600 We create a new context, and can select the schema provided
07700 by our two decisions about INPUT:
07800 (DEFINEQ (←fn (LAMBDA ←arglist ←assign1 ←assign2 ... ←assignN))), then
07900 (DEFINEQ (INPUT:1 (LAMBDA (ELEMENT) (SETQ ELEMENT (READ))
08000 (SETQ part1:of:ELEMENT corresponding:part:of:ELEMENT)
08100 (SETQ part2:of:ELEMENT corresponding:part:of:ELEMENT)
08200 .
08300 .
08400 .
08500 (SETQ partN:of:ELEMENT corresponding:part:of:ELEMENT)]
08600 and then
08700 (DEFINEQ (INPUT:1 (LAMBDA (ELEMENT) (SETQ ELEMENT (READ))
08800 (SETQ objects corresponding:part:of:ELEMENT)
08900 (SETQ static:relations corresponding:part:of:ELEMENT)
09000 (SETQ indicator:of:CLASS:NAME (CAR ELEMENT))]
09100
09200 At this point, we are making assertions about what we're doing, and one of
09300 them is "We are deciding how to get relations from input". This triggers
09400 the demon created for decision (4), whether instances are left in view
09500 indefinitely or only for a limited time.
09600
09700 OBEY:DEMON (RESOLVE:DECISION)
09800 Since we have no relevant information to aid us, we must ask.
09900
10000 MESSAGE
10100 "Pup: Sorry to bother you, but I must ask this now:
10200 Are instances left in view indefinitely, or only for a limited period
10300 of time?"
10400 end of MESSAGE
10500
10600 Say User types: "only for a limited time". Then Pup
10700 asserts that the new relations are in fact gotten all at once, in the SETQ,
10800 and then some subset will eventually get stored somewhere, and the rest
10900 will be wiped out when the limited time is up. The preence of all relations
11000 at the beginning means that if we are looking for a relation and it is
11100 absent, then we can assume that it is actually lacking in the scene. This
11200 is a very important assumption, and perhaps we should print it to get
11300 the user's okay. The alternative is to ask the user what can be surmised
11400 from the absence of a relation. If nothing, then it will be much rarer
11500 that we get any contradiction: only when the negation of a YES relation
11600 is present, unlike the "when a YES relation is absent" rule that Winston's
11700 program used. This is sort of jumping the gun, but it is a very important
11800 assumption, and Pup should realize this point. Pup looks around and sees
11900 that the easiest way to do this would be to let them be wiped out when
12000 the SETQ is executed next time. Pup phrases this nicely, and asks the
12100 user, "An easy limit is: FOrgotten when next instance appears. OK?". Say
12200 the user agrees. From programming knowledge, we know that this is what
12300 will happen automaitically. In fact, leaving them in view indefinitely would
12400 require special work: a new data structure to store old instances in their
12500 entirety would have to be created. Thus, this is actually easier: we
12600 don't have to take any explicit action now.
12700 end of OBEY:DEMON (RESOLVE:DECISION)
12800
12900 Back in ENCODE, we find that some of the variables -- objects,
13000 not functions -- are not defined. From programming knowledge, Pup
13100 knows that those on the left side of assignments need be given names,
13200 those on the right side must have a value. So these latter may be
13300 functions after all. Pup knows that before defining a function,
13400 before even getting its name, we must have a way of referring to what
13500 it does. In this case, we must get the names on the left before we
13600 worry about the functions on the right.
13700
13800 GET:NAME
13900
14000 PLAUSIBLE:NAMES
14100 {OBJECTS, O, SET:OF:OBJECTS, LIST:OF:OBJECTS,
14200 OBJECTS:OF:ELEMENT, SOO, LOO, SO, LO, SET:OF:OBJECTS:OF:ELEMENT,
14300 LIST:OF:OBJECTS:OF:ELEMENT}
14400 end of PLAUSIBLE:NAMES
14500
14600 MESSAGE
14700 Asks what we want to call them.
14800 end of MESSAGE
14900
15000 Say user types "LIST:OF:OBJECTS:OF:ELEMENT".
15100 end of GET:NAME
15200
15300 GET:NAME
15400
15500 PLAUSIBLE:NAMES
15600 {STATIC:RELATIONS, RELATIONS, STATIC, SR, S, R,
15700 SET:OF:STATIC:RELATION, LIST:OF:STATIC:RELATIONS,
15800 STATIC:RELATIONS:OF:OBJECTS, STATIC:RELATIONS:OF:ELEMENT,
15900 STATIC:RELATIONS:OF:OBJECTS:OF:ELEMENT, SRE, SROE, SRO}
16000 end of PLAUSIBLE:NAMES
16100
16200 MESSAGE
16300 Asks user.
16400 end of MESSAGE
16500
16600 Say user types "SET:OF:RELATIONS".
16700 end of GET:NAME
16800
16900 GET:NAME
17000
17100 PLAUSIBLE:NAMES
17200 {INDICATOR:OF:CLASS:NAME, INDICATOR:OF:HAS:NAME,
17300 CLASS:NAME, INDICATOR, IOCN, IOC, IO, I, IOHN, IOH, CN, C}.
17400 Of these, some are rejected: CLASS:NAME, I, C. But the fringe
17500 of conciousness demon reinstates CLASS:NAME, with a special note
17600 to the user.
17700 end of PLAUSIBLE:NAMES
17800
17900 MESSAGE
18000 end of MESSAGE
18100
18200 Say user types back CLASS:NAME.
18300 end of GET:NAME
18400
18500 Back in ENCODE, our piece of code now looks like:
18600 (DEFINEQ (INPUT:1 (LAMBDA (ELEMENT) (SETQ ELEMENT (READ))
18700 (SETQ LIST:OF:OBJECTS:OF:ELEMENT corresponding:part:of:ELEMENT)
18800 (SETQ SET:OF:RELATIONS corresponding:part:of:ELEMENT)
18900 (SETQ CLASS:NAME (CAR ELEMENT)) )))
19000
19100 As soon as we definitely used READ, a few demons woke up and began
19200 watching to ensure we didn't plunge ahead on a task that was nothing
19300 more than I/O formatting: this latter task can easily be done from
19400 example(s) (eg: Shaw-like program synthesis) near the very end of the
19500 task. This situation occurs, as we begin to consider the undefined
19600 functions on the right sides of the assignments. So Pup makes a note
19700 for each that it still has to be defined, but that it will wait until
19800 near the end, when an example or two will be called for. So for
19900 all other purposes, INPUT:1 has been defined.
20000 end of ENCODE
20100
20200 Now we are finished with this chore; we may want to modify our
20300 preconceptions of INPUT based on this example; this feature is fairly
20400 perceptronic and will be omitted on this pass of the system. A first
20500 step would be to split INPUT into two concepts, if we have a new
20600 variant of it which is used often (more than once -- HACKER).
20700 end of ADAPT:PRECONCEIVED:FUNCTION
20800
20900 Back in REPEATEDLY loop of WRITE:PROGRAM. No, CF is not done yet.
21000
21100 ADAPT:PRECONCEIVED:FUNCTION
21200
21300 CHOOSE
21400
21500 REPEATEDLY
21600
21700 GENERATE
21800 Gives INPUT. This is the second call, and is quite probably
21900 not identical to the first variant INPUT:1.
22000 end of GENERATE
22100
22200 COMPARE
22300 Of course, picks INPUT.
22400 end of COMPARE
22500
22600 GENERATE
22700 Produces DETERMINE
22800 end of GENERATE
22900
23000 COMPARE
23100 Chooses INPUT since it is easier, it occurs before DETERMINE in a
23200 SERIES, and we already have INPUT fresh in our mind.
23300 end of COMPARE
23400
23500 GENERATE
23600 fails
23700 end of GENERATE
23800
23900 end of REPEATEDLY
24000
24100 end of CHOOSE
24200
24300 Once again, INPUT is the preconceived function we must adapt.
24400 In particular, we shall now work on what was the second call to INPUT,
24500 namely (INPUT CLASS:NAME) in the definition of PARTITION:A:DOMAIN.
24600 First, we replace INPUT here by INPUT:2. We RECALL (using fringe demon)
24700 that there were two decisions involved in filling in an INPUT body, and
24800 both had to be made before proceeding. So we immediately investigate.
24900
25000 OBEY:DEMON (RESOLVE:DECISION)
25100 This examines whether the object to be inputted has already been
25200 obtained. We are in a series, so there are only two ways we can be
25300 absolutely certain the object was already obtained: (a) we had it before
25400 beginning the series, or (b) we obtained it in a function earlier in the
25500 series. This is a piece of programming knowledge, the stuff that program
25600 verifiers are made of. We know from our various contexts that (a) cannot
25700 hold. The only function to come before the current one in the series
25800 was (INPUT:1 ELEMENT), so (b) reduces to the question, "did we get
25900 CLASS:NAME by executing (INPUT:1 ELEMENT). We examine the Effects part
26000 of INPUT:1, and sure enough one of the assertions is (OBTAINED CLASS:NAME).
26100 So we do always have class:name before reaching this point in the series.
26200 Thus the Affect part of the decision (12) being tells us we shall use
26300 an assignment to a variable, not to (READ).
26400 end of OBEY:DEMON (RESOLVE:DECISION)
26500
26600 OBEY:DEMON (RESOLVE:DECISION)
26700 This worries about the number of distinguishable parts of the
26800 object to be inputted. Since Pup knows that CLASS:NAME is a simple
26900 identifier, we easily dispose of this issue.
27000 end of OBEY:DEMON (RESOLVE:DECISION)
27100
27200 Now we are ready to encode INPUT:2.
27300
27400 ENCODE
27500 We create a new context, and select the simple schema
27600 (DEFINEQ (←fn (LAMBDA ←arglist ←assign1))), then we instantiate it as
27700 (DEFINEQ (INPUT:2 (LAMBDA (CLASS:NAME) (SETQ CLASS:NAME proper:variable))))
27800 By examining the details of decision (12), we see that the proper variable
27900 referred to is simply the name of the equivalent previously-obtained
28000 variable. Programming knowledge tells us we can get this as the left
28100 side of the assignment statement in the function where it is created.
28200 In our case, this function is INPUT:1, the statement is
28300 (SETQ CLASS:NAME (CAR ELEMENT)), so the proper:variable is CLASS:NAME.
28400 Thus we rewrite our function as (DEFINEQ (INPUT:2 (LAMBDA (CLASS:NAME)
28500 (SETQ CLASS:NAME CLASS:NAME)))). A program-optimization demon recognizes
28600 this as trivial at best, an error at worst. So he flags this as an
28700 improbable situation. At the end, if it is not necessary to change this,
28800 we can entirely eliminate the statement. A similar demon would then
28900 realize that we can eliminate the entire function as well.
29000 end of ENCODE
29100
29200 As before, we may now want to modify the general INPUT being,
29300 create a new INPUT:2 system being (if we think it will be used often).
29400 But we will not do this in our first pass at a system, so let's go on.
29500 end of ADAPT:PRECONCEIVED:FUNCTION
29600
29700 The REPEATEDLY loop goes on.
29800 ADAPT:PRECONCEIVED:FUNCTION
29900
30000 CHOOSE
30100
30200 REPEATEDLY
30300
30400 GENERATE
30500 Gives DETERMINE.
30600 end of GENERATE
30700
30800 COMPARE
30900 Picks DETERMINE of course.
31000 end of COMPARE
31100
31200 GENERATE
31300 fails.
31400 end of GENERATE
31500
31600 end of REPEATEDLY
31700
31800 end of CHOOSE
31900
32000 So we are going to adapt the known function DETERMINE. In particular
32100 we are adapting it in the call (DETERMINE CLASS:NAME) in the situation
32200 (NOT (HAS:NAME ELEMENT)) which is of course (EQUAL (CAR ELEMENT)
32300 (QUOTE ?)). DETERMINE comes in several flavors, as reflected by its TYPEs.
32400
32500 TYPE
32600 In this category of the DETERMINE being we find various decisions:
32700 (14) Does an algorithm for getting x already exist?
32800 Affect: Whether we can adapt the preexisting algorithm or not.
32900 When: Before attempting to code DETERMINE.
33000
33100 (15) Does an algorithm already exist which gets x as well as doing other
33200 things?
33300 Affect, When are same as (14) above.
33400
33500 (16) Determining may have the character of:
33600 (a) Computing (eg, determining the roots of an equation)
33700 (b) Searching a known, finite space for an x with certain properties.
33800 (c) Generating and testing in an unknown space.
33900 Affect: Which template of DETERMINE to start coding from.
34000
34100 (17) In case of error, we must do something:
34200 (a) Nothing; proceed on. (also includes: no possibility of error)
34300 (b) Ability to backtrack to precise context of erroneous choice, then
34400 begin again from that point.
34500 (c) ENough knowledge about choice is stored to enable recovery and
34600 new choice to be made, then continuing on from point of error
34700 discovery.
34800 Affect: Saving of intermediate results, record of determination
34900 process.
35000 When: After knowing what to do if DETERMINE errs;
35100 also, before end of session.
35200
35300 end of TYPE
35400
35500 So decisions 14, 15, and 16 must be made now, and 17 later.
35600
35700 OBEY:DEMON (RESOLVE:DECISION)
35800 Working on (14), we see find that the only algorithm for
35900 getting classname is (INPUT:2 CLASS:NAME), but this presupposes that
36000 we have already gotten CLASS:NAME. So we must answer negatively.
36100 end of OBEY:DEMON (RESOLVE:DECISION)
36200
36300 OBEY:DEMON (RESOLVE:DECISION)
36400 Working on (15), we find the algorithm INPUT:1, applied to
36500 ELEMENT, gets CLASS:NAME as one of its effects. To be at the
36600 DETERMINE call, we know that the value obtained was "?". Thus, using
36700 INPUT:1 would mean always having CLASS:NAME equal to ?. This is very
36800 improbable, and marked as such, although we tentatively assume it.
36900 We know that if this is true, then the answer to (16) will be (a).
37000 end of OBEY:DEMON (RESOLVE:DECISION)
37100
37200 OBEY:DEMON (RESOLVE:DECISION)
37300 Working on (16). We must ask the User to decide.
37400
37500 MESSAGE
37600 "Pup: When I DETERMINE CLASS:NAME, does determining have
37700 the character of (a) computing, calculating, simple retrieving
37800 (b) Searching through a known, finite space of possibilities,
37900 (c) Searching an unknown space by generation and testing. ?".
38000 end of MESSAGE
38100
38200 Say user types "(b)". This immediately gets translated
38300 to "Search through a known, finite space of possibilities", thence to
38400 (CHOOSE:FROM space:of:possibilites). So we eliminate our previous
38500 guess about decision (15), which we thought was pretty unlikely anyway.
38600 Also, we now know which DETERMINE template to use: the CHOOSE:FROM one.
38700 end of OBEY:DEMON (RESOLVE:DECISION)
38800
38900 So we now feel ready to code DETERMINE.
39000
39100 ENCODE
39200 We create a new context, and replace the use of DETERMINE by
39300 DETERMINE:1. We pick the CHOOSE:FROM template (schema) which is
39400 (DEFINEQ (←fn (LAMBDA ←arglist (FOREACH ←member IN ←space:of:possibilities
39500 DO ←test:member:for:suitability)))). This can be instantiated to
39600
39700 (DEFINEQ (DETERMINE:1 (LAMBDA (CLASS:NAME)
39800 (FOREACH ←possible:CLASS:NAME IN ←space:of:possible:CLASS:NAMES
39900 DO ←test:possible:CLASS:NAME:for:suitability)))).
40000
40100 REPEATEDLY
40200
40300 FILL:IN:UNDEFINED:SECTION
40400
40500 CHOOSE
40600
40700 REPEATEDLY
40800
40900 GENERATE
41000 Gives possible:CLASS:NAME
41100 end of GENERATE
41200
41300 COMPARE
41400 Picks possible:CLASS:NAME
41500 end of COMPARE
41600
41700 GENERATE
41800 Gives us space:of:possible:CLASS:NAMES
41900 end of GENERATE
42000
42100 COMPARE
42200 This new entry is essentially dependent upon the first.
42300 end of COMPARE
42400
42500 GENERATE
42600 GIves test:possible:CLASS:NAME:for:suitability.
42700 end of GENERATE
42800
42900 COMPARE
43000 This is a function of possible:CLASS:NAME, thus it is
43100 inherently more complex and should be done later.
43200 end of COMPARE
43300
43400 GENERATE
43500 fails
43600 end of GENERATE
43700
43800 end of REPEATEDLY
43900
44000 end of CHOOSE
44100
44200 Thus we have chosen to work on possible:CLASS:NAME.
44300 We know that this is an object, an identifier, and in fact just a dummy
44400 variable. Thus we won't worry too much about it. Pup will not even
44500 bother asking the User what to call it, since he should not have to
44600 refer to dummy variables by name.
44700
44800 GET:NAME
44900
45000 PLAUSIBLE:NAMES
45100 {POSSIBLE:CLASS:NAME, POSSIBLE:CLASS, POSSIBLE,
45200 PCN, PC, P, POS:CLASS:NAME, POS:CLASS, CLASS:NAME, CN}
45300 We eliminate CLASS:NAME, P.
45400 end of PLAUSIBLE:NAMES
45500
45600 We merely select the first plausible name, say it is
45700 POSSIBLE:CLASS:NAME.
45800 end of GET:NAME
45900
46000 end of FILL:IN:UNDEFINED:SECTION
46100
46200 Back in REPEATEDLY, we aren't completed DETERMINE:1 yet.
46300
46400 FILL:IN:UNDEFINED:SECTION
46500
46600 CHOOSE
46700
46800 REPEATEDLY
46900
47000 GENERATE
47100 space:of:POSSIBLE:CLASS:NAMES
47200 end of GENERATE
47300
47400 COMPARE
47500 end of COMPARE
47600
47700 GENERATE
47800 test:POSSIBLE:CLASS:NAME:for:suitability
47900 end of GENERATE
48000
48100 COMPARE
48200 Since it is mentioned later, examined later, and
48300 is a function instead of an object, we choose to defer its examination.
48400 end of COMPARE
48500
48600 GENERATE
48700 fails
48800 end of GENERATE
48900
49000 end of REPEATEDLY
49100
49200 end of CHOOSE
49300
49400 So we must fill in details about the space of possible class
49500 names. We know that this is an identifier, the name of a group. We
49600 may have need to refer to it, so we must get the name by asking.
49700
49800 GET:NAME
49900
50000 PLAUSIBLE:NAMES
50100 {SPACE:OF:POSSIBLE:CLASS:NAMES, SPACE, SOPCN, S,
50200 SET:OF:POSSIBLE:CLASS:NAMES, LIST:OF:POSSIBLE:CLASS:NAMES, LOPCN,
50300 POSSIBLE:CLASS:NAMES, CLASS:NAMES, SPACE:OF:CLASS:NAMES, CN, PCN}
50400 end of PLAUSIBLE:NAMES
50500
50600 MESSAGE
50700 "Pup: What do you wish to call the space of poosible
50800 class names? SOme plausible suggestions are...?"
50900 end of MESSAGE
51000
51100 Say user types back LIST:OF:POSSIBLE:CLASS:NAMES.
51200 end of GET:NAME
51300
51400 end of FILL:IN:UNDEFINED:SECTION
51500
51600 No, we aren't done with DETERMINE:1 yet, so we go on.
51700
51800 CHOOSE
51900
52000 REPEATEDLY
52100
52200 GENERATE
52300 test:POSSIBLE:CLASS:NAME:for:suitability
52400 end of GENERATE
52500
52600 COMPARE
52700 end of COMPARE
52800
52900 GENERATE
53000 fails
53100 end of GENERATE
53200
53300 end of REPEATEDLY
53400
53500 end of CHOOSE
53600
53700 We must now fill in the details about the function which
53800 tests POSSIBLE:CLASS:NAME, an element of LIST:OF:POSSIBLE:CLASS:NAMES,
53900 for suitability. Thus, we assert that we are about to decide some of the
54000 details of how we search through the space of concepts. This triggers
54100 the demons associated with decisions (6) and (10).
54200
54300 OBEY:DEMON (RESOLVE:DECISION)
54400 We must ask the user.
54500
54600 MESSAGE
54700 "Pup: is transfer present? That is, do previously
54800 learned concepts affect the learning of entirely new concepts?
54900 Answer (a) positive, (b) negative, (c) both, (d) neither."
55000 end of MESSAGE
55100
55200 Say user types (d). So nothing need be done now.
55300 end of OBEY:DEMON (RESOLVE:DECISION)
55400
55500 OBEY:DEMON
55600 We still aren't sure about how strict the user's
55700 usage of "partition" was. We must now pin him down on it.
55800
55900 MESSAGE
56000 "Pup: Please tell me if your usage of the
56100 word partition was in the strict mathematical sense. In particular
56200 please answer the following two questions yes or no:
56300 (i) Can one element belong to two different classes
56400 (ii) Can an element fail to belong to any class
56500 end of MESSAGE
56600
56700 Say user types no to each question. So we just
56800 go on with our work.
56900 end of OBEY:DEMON
57000
57100 One note tells us that we could view this as applying a variant of the
57200 known function TEST to the element POSSIBLE:CLASS:NAME, with the
57300 "for suitability" as a note to TEST. We look around for other possibilites
57400 and find none, so we do this. We now have finished with DETERMINE:1,
57500 but we have introduced a new task: adapt TEST.
57600 end of FILL:IN:UNDEFINED:SECTION
57700
57800 The code for DETERMINE:1 is completely finished now:
57900 (DEFINEQ (DETERMINE:1 (LAMBDA (CLASS:NAME)
58000 (FOREACH POSSIBLE:CLASS:NAME IN LIST:OF:POSSIBLE:CLASS:NAMES
58100 DO (TEST POSSIBLE:CLASS:NAME)
58200 )
58300 )))
58400 end of REPEATEDLY
58500
58600 end of ENCODE
58700
58800 end of ADAPT:PRECONCEIVED:FUNCTION
00100
00200 Back in REPEATEDLY loop of WRITE:PROGRAM. CF isn't completed yet.
00300
00400 ADAPT:PRECONCEIVED:FUNCTION
00500
00600 CHOOSE
00700
00800 REPEATEDLY
00900
01000 GENERATE
01100 Produces FOREACH
01200 end of GENERATE
01300
01400 COMPARE
01500 end of COMPARE
01600
01700 GENERATE
01800 Produces TEST
01900 end of GENERATE
02000
02100 COMPARE
02200 Our knowledge of FOREACH tells us to try to get knowledge
02300 of its components before trying to code it.
02400 end of COMPARE
02500
02600 GENERATE
02700 fails
02800 end of GENERATE
02900
03000 end of REPEATEDLY
03100
03200 end of CHOOSE
03300
03400 So we must adapt TEST now. Specifically, we are adapting it to the
03500 call in FOREACH, in DETERMINE:1, in the series of PARTITION:A:DOMAIN.
03600 The argument is POSSIBLE:CLASS:NAME, and the situation has the features:
03700 CLASS:NAME is "?", ELEMENT has just been read in, and with it
03800 LIST:OF:OBJECTS:OF:ELEMENT and SET:OF:RELATIONS have been assigned.
03900 We now look at the flavors of testing:
04000
04100 TYPE
04200 Here we look at the possible choices:
04300 (18) Testing may have the character of:
04400 (a) Comparing the object with some distinguished object
04500 (b) Letting the object compete with its fellows for supremacy
04600 Affect: Which template of TEST to use.
04700
04800 (19) What type of test result is wanted
04900 (a) Nominal: satisfactory/ unsatisfactory
05000 (b) Ordinal: relative ranking of objects tested
05100 (c) Ratio: absolute scale of object's desirability
05200 Affect: if (a) then no other object in space need be examined
05300 if (b) then all other objects in space need be examined
05400 if (c) the all other objects in space need be examined
05500 and also an absolute scale must be obtained.
05600 end of TYPE
05700
05800 So decision (18) must be resolved before coding, and (similar to
05900 decision (1)) we must resolve decision (19) only whether a or b-c, since
06000 latter choice has nonvoid intersection.
06100
06200 OBEY:DEMON (RESOLVE:DECISION)
06300 Because of the usage of TEST in a FOREACH loop, it is very
06400 unlikely that the answer to (18) is (b), for then we would not be
06500 using the FOREACH at all. So we add a note that if we are wrong
06600 we change to the all-competing test template, and we choose the
06700 compare with criteria template.
06800 end of OBEY:DEMON (RESOLVE:DECISION)
06900
07000 OBEY:DEMON (RESOLVE:DECISION)
07100 Because of imbedded usage in DETERMINE, where we are ultimately
07200 selecting a single element of the space, we decide that probably (a)
07300 is the right answer. We don't bother asking the user, so we make a
07400 note of how to alter the program if we were mistaken in our choice.
07500 end of OBEY:DEMON (RESOLVE:DECISION)
07600
07700 We should be ready to begin coding TEST.
07800 But we are in the situation of firmly deciding some of the details of
07900 identification of ELEMENT. This triggers the decision (3) demon.
08000
08100 OBEY:DEMON (RESOLVE:DECISION)
08200 We know nothing more about this, so we ask.
08300
08400 MESSAGE
08500 "Pup: Sorry to bother you, user, but I must know this now.
08600 Is the speed of presentation of instances a relevant factor?"
08700 end of MESSAGE
08800
08900 Say user types back that it is not. So we needn't do anything.
09000 end of OBEY:DEMON (RESOLVE:DECISION)
09100
09200 ENCODE
09300 We create a new context, and replace TEST by TEST:1. Now we
09400 use the comparison template of testing,
09500 (DEFINEQ (←fn (LAMBDA ←arglist (COMPARE ←arg ←distinguished:object))))
09600 which becomes
09700 (DEFINEQ (TEST:1 (LAMBDA (POSSIBLE:CLASS:NAME)
09800 (COMPARE POSSIBLE:CLASS:NAME ←distinguished:object) ))).
09900
10000 We can once again observe that in order for this not to be identical
10100 every time, we must have a different distinguished:element each time
10200 we execute this piece of code. So, what is "new" about this situation.
10300 Answer, by querying net, is ELEMENT, SET:OF:RELATIONS,
10400 and LIST:OF:OBJECTS:OF:ELEMENT. Compare is a general routine which
10500 compares attributes of parts of its arguments, of information associated
10600 with its arguments, and so on. Thus, our programming knowledge tells
10700 us that if we are not sure whehter to compare something to x or to y,
10800 if x contains y, then we can definitely assume it is "compare to x".
10900 Thus we assume the distinguished element is ELEMENT.
11000
11100 (DEFINEQ (TEST:1 (LAMBDA (POSSIBLE:CLASS:NAME)
11200 (COMPARE POSSIBLE:CLASS:NAME ELEMENT) )))
11300 end of ENCODE
11400
11500 end of ADAPT:PRECONCEIVED:FUNCTION
11600
11700 Back in the outermost REPEATEDLY, we again see CF isn't done.
11800
11900 ADAPT:PRECONCEIVED:FUNCTION
12000
12100 CHOOSE
12200
12300 REPEATEDLY
12400
12500 GENERATE
12600 Produces FOREACH
12700 end of GENERATE
12800
12900 COMPARE
13000 FOREACH is chosen.
13100 end of COMPARE.
13200
13300 GENERATE
13400 Produces COMPARE
13500 end of GENERATE
13600
13700 COMPARE
13800 Chooses COMPARE since it is "inside" FOREACH.
13900 end of COMPARE
14000
14100 GENERATE
14200 fails
14300 end of GENERATE
14400
14500 end of REPEATEDLY
14600
14700 end of CHOOSE
14800
14900 So we are going to adapt the generalized COMPARE function, with
15000 arguments POSSIBLE:CLASS:NAME and ELEMENT, in the contest of TEST:1,
15100 inside FOREACH, inside DETERMINE:1, inside the series of PARTITION:A:
15200 DOMAIN. There are some variations of comparison we must look at.
15300
15400 TYPE
15500 We examine the choices:
15600 (20) Comparing may involve:
15700 (a) A simple known function, such as equality, applied directly.
15800 (b) A more sophistocated procedure, again applied directly.
15900 (c) A simple known function applied to certain entities associated
16000 with the arguments: some subparts, property-list entries, etc.
16100 (d) A more complex procedure applied to entities associated with
16200 the arguments.
16300 Affect: Template to use for comparison.
16400
16500 (21) Type of result of comparison desired. May range from one bit
16600 (yes/no) to a vector of absolute values along certain dimensions.
16700 Affect: Details of code, termination of comparison.
16800
16900 end of TYPE
17000
17100 ENCODE
17200 Before choosing a template, there are some "global" preconditions
17300 to satisfy. In particular, we must know the structure of each argument,
17400 and what information entities are associated with each. As soon as
17500 we assert that we are going to look for this, the demon for decision
17600 (5) is activated.
17700
17800 OBEY:DEMON (RESOLVE:DECISION)
17900 We must decide about the logical complexity of the concepts
18000 before we decide anything about how they are stored. We have no new
18100 information relevant to this point, so we must ask the user.
18200
18300 MESSAGE
18400 "Pup: I must know now how logically complex the concepts
18500 to be learned will possibly be:
18600 (a) Purely conjunctive
18700 (b) Purely disjunctive
18800 (c) More complex"
18900 end of MESSAGE
19000
19100 Say user types "(a)". We record the answer, and notice that
19200 this is simple enough that we needn't do anything else at this time.
19300 end of OBEY:DEMON (RESOLVE:DECISION)
19400
19500 Now we are permitted to begin getting details about
19600 POSSIBLE:CLASS:NAME and its associated data, and about ELEMENT
19700 and its associates. We already know a great deal about ELEMENT,
19800 namely that it is composed of a CLASS:NAME which is currently "?",
19900 a LIST:OF:OBJECTS:OF:ELEMENT, and a SET:OF:RELATIONS which are static
20000 relations between the objects. When comparing two entities, we often
20100 compare corrsponding sub-parts. This is more fully pinned by decision
20200 (20), but for now it causes us to suspect that there may be a list
20300 of objects and a set of relations among objects and a class name,
20400 all associated with POSSIBLE:CLASS:NAME. We note that if this is true
20500 then we must later determine how we set up this information.
20600 We now turn to resolving decision (20).
20700
20800 OBEY:DEMON (RESOLVE:DECISION)
20900 What does the comparison involve. We aren't sure, but we
21000 doubt whether it is (a) or (b) since ELEMENT is so highly structured.
21100 We know that (d) contains (c), so we needn't bother the user just yet.
21200 end of OBEY:DEMON (RESOLVE:DECISION)
21300
21400 So now we pick up the schema
21500 (DEFINEQ (COMPARE (LAMBDA (←arg1 ←arg2)
21600 (join:comparisons
21700 (COMPARE:1 ←part1:of:arg1 ←part1:of:arg2)
21800 .
21900 .
22000 .
22100 (COMPARE:N ←partN:of:arg1 ←partN:of:arg2)]
22200 This then gets turned into
22300 (DEFINEQ (COMPARE:1 (LAMBDA (POSSIBLE:CLASS:NAME ELEMENT)
22400 (join:comparisons
22500 (COMPARE:1:1 ←LIST:OF:OBJECTS:corresponding:to:POSSIBLE:CLASS:NAME
22600 LIST:OF:OBJECTS:OF:ELEMENT)
22700 (COMPARE:1:2 ←SET:OF:static:RELATIONS:corresponding:to:POSSIBLE:CLASS:
22800 NAME
22900 SET:OF:RELATIONS)) )))
23000 Notice that we do not try to compare anything to CLASS:NAME of ELEMENT,
23100 since we know it is a constant, always question-mark if we are in this
23200 call to COMPARE:1.
23300
23400 FILL:IN:UNDEFINED:SECTION
23500
23600 CHOOSE
23700
23800 REPEATEDLY
23900
24000 GENERATE
24100 Produces LIST:OF:OBJECTS:corresponding:to:POSSIBLE:CLASS:
24200 NAME.
24300 end of GENERATE
24400
24500 COMPARE
24600 end of COMPARE
24700
24800 GENERATE
24900 Produces join:comparisons.
25000 end of GENERATE
25100
25200 COMPARE
25300 Latter is fn. of former, so former is preferable.
25400 end of COMPARE
25500
25600 GENERATE
25700 This time we generate the undefined object
25800 SET:OF:static:RELATIONS:corresponding:to:POSSIBLE:CLASS:NAME.
25900 end of GENERATE
26000
26100 COMPARE
26200 Again, since it was considered later and occurs as a
26300 later argument than LIST:OF:OBJECTS:corr... we shall defer it.
26400 end of COMPARE
26500
26600 GENERATE
26700 fails
26800 end of GENERATE
26900
27000 end of REPEATEDLY
27100
27200 end of CHOOSE
27300
27400 We assert that Pup is about to fill in details about
27500 LIST:OF:OBJECTS:corresponding:to:POSSIBLE:CLASS:NAME.
27600 What do we know? It is probably a list; we get this since it should
27700 correspond to LIST:OF:OBJECTS:OF:ELEMENT in structure. Since we
27800 know a lot about comparing two list strucutres, all we need now is
27900 a name for it.
28000
28100 GET:NAME
28200
28300 PLAUSIBLE:NAMES
28400 end of PLAUSIBLE:NAMES
28500
28600 MESSAGE
28700 "Pup: What do you want to call the list of objects
28800 corresponding to POSSIBLE:CLASS:NAME? Some plausible names are..."
28900 end of MESSAGE
29000
29100 Say user types LIST:OF:OBJECTS:OF:POSSIBLE:CLASS.
29200 end of GET:NAME
29300
29400 We are aware of the note about not knowing how this list
29500 is built up, and we continue to defer worrying about it.
29600 end of FILL:IN:UNDEFINED:SECTION
29700
29800 Code for COMPARE:1 is not yet totally defined.
29900
30000 FILL:IN:UNDEFINED:SECTION
30100
30200 CHOOSE
30300
30400 REPEATEDLY
30500
30600 GENERATE
30700 .
30800 .
30900 .
31000 Here we generate and compare just as last time,
31100 and we come up with our next choice:
31200 SET:OF:static:RELATIONS:corresponding:to:POSSIBLE:
31300 CLASS:NAME.
31400 .
31500 .
31600 .
31700 end of GENERATE
31800
31900 end of REPEATEDLY
32000
32100 end of CHOOSE
32200
32300 We assert what we are about to work on. As before, we know
32400 a lot about comparing sets, so we just need a name for this object.
32500
32600 GET:NAME
32700 Similar to before, we ask user. Say he types back
32800 "SET:OF:RELATIONS:OF:POSSIBLE:CLASS".
32900 en of GET:NAME
33000
33100 end of FILL:IN:UNDEFINED:SECTION
33200
33300 We still aren't finished with COMPARE:1.
33400
33500 FILL:IN:UNDEFINED:SECTION
33600
33700 CHOOSE
33800 We arrive at choice join-comparisons by default.
33900 end of CHOOSE
34000
34100 We assert that we are going to fill in the undefined section
34200 currently marked by "join:comparisons". We understand that this is a
34300 combining of intermediate results, and is typically something simple
34400 like AND, OR, SERIES, XOR, LIST. The precise choice is basically
34500 determined by what type of result is wanted, when to terminate the
34600 comparison, what type of result each of the comparisons returns.
34700 So we assert that we are now going to decide when to terminate the
34800 comparison. This activates demon from decision (21).
34900
35000 OBEY:DEMON (RESOLVE:DECISION)
35100 We don't know any more about this than before, so we ask.
35200
35300 MESSAGE
35400 "Pup: When do I stop comparing ELEMENT to a given
35500 POSSIBLE:CLASS:NAME?"
35600 end of MESSAGE
35700
35800 Say user types "Stop when any relation in SET:OF:RELATIONS:
35900 OF:POSSIBLE:CLASSis incompatible with SET:OF:RELATIONS ".
36000 This is not comprehensible so RESOLVE DECISION tries to make it usable.
36100
36200 OBTAIN:USABLE:INFORMATION
36300
36400 TRANSLATE
36500
36600 REPEATEDLY
36700
36800 PARSE
36900 (Stop when) (((any) relation) in (SET:OF:RELATIONS:OF
37000 POSSIBLE:CLASS)) (is incompatiple with) (SET:OF:RELATIONS)
37100 end of PARSE
37200
37300 LOOKUP
37400 (Stop when) becomes (DO UNTIL)
37500 end of LOOKUP
37600
37700 LOOKUP
37800 (any) indicates setting up of FORSOME loop.
37900 end of LOOKUP
38000
38100 LOOKUP
38200 relation is recognized as the dummy variable of "any".
38300 end of LOOKUP
38400
38500 LOOKUP
38600 (in) is also recognized as standard part of FORSOME
38700 loop technique.
38800 end of LOOKUP
38900
39000 LOOKUP
39100 (is incompatible with) is recognized as the known
39200 function CONTRADICTS.
39300 end of LOOKUP
39400
39500 end of REPEATEDLY
39600
39700 The final translation is thus something like:
39800 (DO UNTIL (FORSOME RELATION IN SET:OF:RELATIONS:OF:POSSIBLE:CLASS
39900 (CONTRADICTS RELATION SET:OF:RELATIONS)) )).
40000 end of TRANSLATE
40100
40200 end of OBTAIN:USABLE:INFORMATION
40300
40400 Though we will use all of this information, RESOLVE DECISION
40500 just notes that it is of the form DO UNTIL x. This settles (21) to mean
40600 a simple yes/no answer, and in fact to find just the first "yes" and
40700 then quit.
40800 end of OBEY:DEMON (RESOLVE:DECISION)
40900
41000 We are ready now to encode join:comparisons.
41100
41200 ENCODE
41300 A new context is created. We use our programming knowledge
41400 to recognize that COMPARE:1:1 is either totally ignorable, or else is
41500 merely a pre-processing step. In either case we can do the two
41600 comparisons in series. So we replace ←join:comparisons by SERIES.
41700
41800 COMMENT
41900 We add the comment that if nothing new develops, we can
42000 eliminate SERIES, since the definition of a function involves an implicit
42100 use of series. We also add the comment to COMPARE:1:2 that it should
42200 terminate as soon as any relation in SET:OF:RELATIONS:OF:POSSIBLE:CLASS
42300 is contradicted by SET:OF:RELATIONS. We also note that COMPARE:1:1
42400 is executed for side effects only -- if at all. Also we note that
42500 COMPARE:1 and COMPARE:1:2 both return simple yes/no results.
42600 end of COMMENT
42700
42800 end of ENCODE
42900
43000 end of FILL:IN:UNDEFINED:SECTION
43100
43200 We are now finished encoding all of COMPARE:1. Comments relevant
43300 to it already have been made, so we aren't forced to call COMMENT again.
43400 end of ENCODE
43500
43600 end of ADAPT:PRECONCEIVED:FUNCTION
00100
00200 We are again in the REPEATEDLY loop of WRITE;PROGRAM. After
00300 observing the incompleteness of CF, we again choose a course of action.
00400
00500 ADAPT:PRECONCEIVED:FUNCTION
00600
00700 CHOOSE
00800
00900 REPEATEDLY
01000
01100 GENERATE
01200 Produces COMPARE:1:1
01300 end of GENERATE
01400
01500 COMPARE
01600 end of COMPARE
01700
01800 GENERATE
01900 Produces COMPARE:1:2
02000 end of GENERATE
02100
02200 COMPARE
02300 We know that COMPARE:1:1 may be totally superfluous, and this
02400 depends partially upon COMPARE:1:2. Thus we defer COMPARE:1:1 since by
02500 doing so we may never have to work on it at all.
02600 end of COMPARE
02700
02800 GENERATE
02900 Produces CONTRADICTS. Although this isn't in any defined piece
03000 of code yet, it soon will be. Also, we know where it will go and what its
03100 arguments will be.
03200 end of GENERATE
03300
03400 COMPARE
03500 Since the current champ, COMPARE:1:2, depends upon
03600 CONTRADICTS in a fundamental way, we postpone COMPARE:1:2 until we
03700 have completed CONTRADICTS.
03800 end of COMPARE
03900
04000 GENERATE
04100 fails
04200 end of GENERATE
04300
04400 end of REPEATEDLY
04500
04600 end of CHOOSE
04700
04800 So we are going after CONTRADICTS, with arguments RELATION
04900 (an element of SET:OF:RELATIONS:OF:POSSIBLE:CLASS) and SET:OF:RELATIONS.
05000 This call is in COMPARE:1:2, in COMPARE:1, in TEST:1, in DETERMINE:1,
05100 in the series of PARTITION:A:DOMAIN.
05200
05300 ENCODE
05400 A new context is created, CONTRADICTS:1 is substituted in,
05500 and we examine the CONTRADICTS being. It tells us that two relations
05600 contradict each other if it is impossible for both to hold
05700 simultaneously, and for neither to hold. In particular, the absence of
05800 relation r1 holding is a contradiction iff the probability p(r1)
05900 of r1 holding is unity. Also, the presence of r1 holding is a
06000 contradiction iff p(r1) is zero. Thus if p(r1) is strictly
06100 greater than zero and less than one, then it cannot contradict
06200 anything.
06300
06400 CHOOSE:ALGORITHM
06500 Our programming facts contain the little tidbit:
06600 When we must do f(x), if x is divisible into a few parts,
06700 and f on each part of x is a different procedure, then define
06800 f as a group of functions, which operate on different parts of x.
06900 end of CHOOSE:ALGORITHM
07000
07100 So we decide that CONTRADICTS will work differently for
07200 the three sections of SET:OF:RELATIONS:OF:POSSIBLE:CLASS, namely
07300 those relations which have p=1, those with p=0, and those with
07400 0<p<1.
07500 In particular, if RELATION is in the p=1 set, then CONTRADICTS is
07600 equivalent to : RELATION is not in SET:OF:RELATIONS.
07700 If RELATION is in the p=0 set, then CONTRADICTS is
07800 equivalent to : RELATION is in SET:OF:RELATIONS.
07900 If RELATION is in the 0<p<1 group, then CONTRADICTS must be false.
08000 We thus define our function:
08100 (DEFINEQ (CONTRADICTS (LAMBDA (←relation ←set:of:relations)
08200 (COND ((MEMBER RELATION p=1:set) (NOT (MEMBER RELATION SET:OF:RELATIONS
08300 )))
08400 ((MEMBER RELATION p=0:set) (MEMBER RELATION SET:OF:RELATIONS))
08500 ((MEMBER RELATION 0<p<1:set) NIL)
08600 ) )))
08700 This triggers a programming:style demon, who winces at this awful form.
08800 He looks closer at the results of the last CHOOSE:ALGORITHM and sees a
08900 note that if the result is awkward, one big improvement is to replace
09000 the single call to f by (a) one call to some fi, if the call to f was in
09100 an existential loop; (b) calls to f1,... fN, if the call to f was in a
09200 universal loop. This will also probably affect the data structure of
09300 how x is stored. Before proceeding with the coding of CONTRADICTS, we
09400 see if we can carry out this change. It involves the call to
09500 CONTRADICTS, in COMPARE:1:2. But this latter hasn't been firmly decided
09600 yet, so it is worth our while to do the transformation. All we do is
09700 change the COMMENTs. Instead of being unstructured,
09800 SET:OF:RELATIONS:OF:POSSIBLE:CLASS will be composed of three separate
09900 pieces, each of which is (as far as we know) an unstrucutred set.
10000 COMPARE:1:2 will compare each piece with SET:OF:RELATIONS, and the
10100 three FOREACH loops will have three UNTIL clauses, with three
10200 different calls onto three versions of CONTRADICTS.
10300 CONTRADICTS:1 will be called during processing of the p=1 group,
10400 (DEFINEQ (CONTRADICTS:1 (LAMBDA (p=1:RELATION SET:OF:RELATIONS)
10500 (NOT (MEMBER p=1:RELATION SET:OF:RELATIONS)) )))
10600 The second variant, CONTRADICTS:2, will work on the p=0 set.
10700 (DEFINEQ (CONTRADICTS:2 (LAMBDA (p=0:RELATION SET:OF:RELATIONS)
10800 (MEMBER p=0:RELATION SET:OF:RELATIONS) )))
10900 The final variant works on members of the 0<p<1 set of relations.
11000 (DEFINEQ (CONTRADICTS:3 (LAMBDA (0<p<1:RELATION SET:OF:RELATIONS)
11100 NIL )))
11200 We thus scrap the earlier tentative definition of CONTRADICTS.
11300 We aren't through encoding the function(s), since undefined identifiers
11400 remain. We merely need to get their names.
11500
11600 GET:NAME
11700
11800 PLAUSIBLE:NAMES
11900 {P=1, PROBABILITY=1, PROBABILITY:IS:ONE, YES, DEFINITE,
12000 P=1:RELATION, PROBABLITY:IS:ONE:RELATION, YES:RELATION, DEFINITE:RELATION,
12100 P=1:R, P1R, YR, DR}
12200 end of PLAUSIBLE:NAMES
12300
12400 Since this is just a dummy variable, we pick one, say
12500 YES:RELATION, without asking the user.
12600 end of GET:NAME
12700
12800 GET:NAME
12900 Similarly, we pick NO:RELATION to replace p=0:RELATION.
13000 end of GET:NAME
13100
13200 GET:NAME
13300 Similarly, we pick MAYBE:RELATION for 0<p<1:RELATION.
13400 end of GET:NAME
13500
13600 All the CONTRADICTS code is defined now.
13700 end of ENCODE
13800
13900 end of ADAPT:PRECONCEIVED:FUNCTION
14000
14100 Back in outermost REPEATEDLY loop again.
14200
14300 ADAPT:PRECONCEIVED:FUNCTION
14400
14500 CHOOSE
14600
14700 REPEATEDLY
14800
14900 GENERATE
15000 Produces COMPARE:1:1
15100 end of GENERATE
15200
15300 COMPARE
15400 end of COMPARE
15500
15600 GENERATES
15700 Produces COMPARE:1:2
15800 end of GENERATE
15900
16000 COMPARE
16100 As before, we prefer COMPARE:1:2.
16200 end of COMPARE
16300
16400 GENERATE
16500 fails
16600 end of GENERATE
16700
16800 end of REPEATEDLY
16900
17000 end of CHOOSE
17100
17200 So we are going to adapt COMPARE, the version COMPARE:1:2.
17300 We know the structure of SET:OF:RELATIONS:OF:POSSIBLE:CLASS, namely
17400 three distinct sets: SET:OF:YES:RELATIONS, SET:OF:NO:RELATIONS, and
17500 SET:OF:MAYBE:RELATIONS.
17600 The structure of SET:OF:RELATIONS seems to be a simple unstructured
17700 set. Decisions (20) and (21) are fresh enough not nto need to call
17800 on TYPE. We again opt for (d) on decision (20), to avoid bothering
17900 the user.
18000
18100 ENCODE
18200 We create a new context and pick a schema:
18300 (DEFINEQ (COMPARE (LAMBDA (←arg1 ←arg2)
18400 (join:comparisons
18500 (COMPARE:1 ←part1:of:arg1 ←part1:of:arg2)
18600 .
18700 .
18800 .
18900 (COMPARE:N ←partN:of:arg1 ←partN:of:arg2)]
19000 This becomes instantiated to:
19100 (DEFINEQ (COMPARE:1:2 (LAMBDA (SET:OF:RELATIONS:OF:POSSIBLE:CLASS
19200 SET:OF:RELATIONS)
19300 (join:comparisons
19400 (COMPARE:1:2:1 SET:OF:YES:RELATIONS SET:OF:RELATIONS)
19500 (COMPARE:1:2:2 SET:OF:NO:RELATIONS SET:OF:RELATIONS)
19600 (COMPARE:1:2:3 SET:OF:MAYBE:RELATIONS SET:OF:RELATIONS)
19700 ) )))
19800 We know that COMPARE:1:2:1 must proceed until CONTRADICTS:1,
19900 COMPARE:1:2:2 terminates if CONTRADICTS:2, and
20000 COMPARE:1:2:3 terminates if CONTRADICTS:3.
20100 These notes are tacked on to the proper places. We know that
20200 COMPARE:1:2 continues until some contradicition is found; thus
20300 the joining of the comparison results must be an AND or a SERIES:
20400 all three must succeed in order for COMPARE:1:2 to succeed.
20500 We tentatively replace join:comparisons by SERIES, and notice
20600 that we haven't decided what order to try the three comparisons.
20700 This is more a personal preference, or a program efficiency item,
20800 so we are not too worried about it. We also note that we shall
20900 have to worry at some time about getting YES:, NO:, and MAYBE:
21000 RELATIONS from SET:OF:RELATIONS:OF:POSSIBLE:CLASS or from one step
21100 higher: from POSSIBLE:CLASS:NAME. This is a data-structure type
21200 of question at best, an initialization worry at worst. So we
21300 don't worry about it now.
21400
21500 COMMENT
21600 Most of the above discussion is tacked on as comments to
21700 COMPARE:1, COMPARE:1:2, COMPARE:1:2:i (i=1,2,3).
21800 end of COMMENT
21900
22000 end of ENCODE
22100
22200 end of ADAPT:PRECONCEIVED:FUNCTION
22300
22400 Back in outer REPEATEDLY. CF isn't complete. We must do something.
22500
22600 ADAPT:PRECONCEIVED:FUNCTION
22700
22800 CHOOSE
22900
23000 REPEATEDLY
23100
23200 GENERATE
23300 COMPARE:1:1
23400 end of GENERATE
23500
23600 COMPARE
23700 end of COMPARE
23800
23900 GENERATE
24000 COMPARE:1:2:1
24100 end of GENERATE
24200
24300 COMPARE
24400 As before, whether or not COMPARE:1:1 is trivial depends
24500 upon COMPARE:1:2 and its pieces.
24600 end of COMPARE
24700
24800 GENERATE
24900 COMPARE:1:2:2
25000 end of GENERATE
25100
25200 COMPARE
25300 We prefer COMPARE:1:2:1 because it comes earlier in series.
25400 end of COMPARE
25500
25600 GENERATE
25700 COMPARE:1:2:3
25800 end of GENERATE
25900
26000 COMPARE
26100 Also comes later in series.
26200 end of COMPARE
26300
26400 GENERATE
26500 Produces FOREACH.
26600 end of GENERATE
26700
26800 COMPARE
26900 As before, we defer FOREACH in lieu of its innards.
27000 end of COMPARE
27100
27200 GENERATE
27300 fails
27400 end of GENERATE
27500
27600 end of REPEATEDLY
27700
27800 end of CHOOSE
27900
28000 So we are going to adapt COMPARE in the call
28100 (COMPARE:1:2:1 SET:OF:YES:RELATIONS SET:OF:RELATIONS) in COMPARE:1:2,
28200 in COMPARE:1.
28300
28400 ENCODE
28500 We create a new context and pick the schema:
28600 (DEFINEQ (COMPARE (LAMBDA (←set1 ←set2)
28700 (FOREACH ←element:of:set1 IN ←set1
28800 DO UNTIL ←until:condition
28900 (COMPARE:1 ←element:of:set1 ←set2)
29000 ) )))
29100 This can be instantiated in our present context as:
29200 (DEFINEQ COMPARE:1:2:1 (LAMBDA (SET:OF:YES:RELATIONS SET:OF:RELATIONS)
29300 (FOREACH:1:2:1 YES:RELATION IN SET:OF:YES:RELATIONS
29400 DO UNTIL (CONTRADICTS:1 YES:RELATION SET:OF:RELATIONS)
29500 (COMPARE:1:2:1:1 YES:RELATION SET:OF:RELATIONS) ) )))
29600 By convention, when we terminate a foreach loop because of an
29700 UNTIL, the value of the loop is NIL. Otherwise, the value is the
29800 one returned by the final call of the function, in this case
29900 COMPARE:1:2:1:1. We look at the purpose of COMPARE:1:2:1 and realize
30000 all we want to know is whether or not we terminated with a
30100 contradicts. Thus we tentatively define COMPARE:1:2:1:1 as T.
30200
30300 COMMENT
30400 The above discussion is formalized, asserted, and commented.
30500 end of COMMENT
30600
30700 end of ENCODE
30800
30900 end of ADAPT:PRECONCEIVED:FUNCTION
31000
31100 Back in REPEATEDLY. We plunge on.
31200
31300 ADAPT:PRECONCEIVED:FUNCTION
31400
31500 CHOOSE
31600
31700 REPEATEDLY
31800
31900 GENERATE
32000 COMPARE:1:1
32100 end of GENERATE
32200
32300 COMPARE
32400 end of COMPARE
32500
32600 GENERATE
32700 COMPARE:1:2:2
32800 end of GENERATE
32900
33000 COMPARE
33100 We prefer COMPARE:1:2:2 for the same reasons as we preferred
33200 COMPARE:1:2:1 last time we had to choose a function.
33300 end of COMPARE
33400
33500 GENERATE
33600 COMPARE:1:2:3
33700 end of GENERATE
33800
33900 COMPARE
34000 Also comes later in series.
34100 end of COMPARE
34200
34300 GENERATE
34400 Produces FOREACH.
34500 end of GENERATE
34600
34700 COMPARE
34800 As before, we defer FOREACH in lieu of its innards.
34900 end of COMPARE
35000
35100 GENERATE
35200 Produces FOREACH:1:2:1
35300 end of GENERATE
35400
35500 COMPARE
35600 This is really a tossup, so suppose we pick a comparison over
35700 a foreach loop when we can't otherwise decide.
35800 end of COMPARE
35900
36000 GENERATE
36100 fails
36200 end of GENERATE
36300
36400 end of REPEATEDLY
36500
36600 end of CHOOSE
36700
36800 So we are going to adapt COMPARE in the call
36900 (COMPARE:1:2:2 SET:OF:NO:RELATIONS SET:OF:RELATIONS) in COMPARE:1:2,
37000 in COMPARE:1.
37100
37200 ENCODE
37300 We create a new context and pick the schema:
37400 (DEFINEQ (COMPARE (LAMBDA (←set1 ←set2)
37500 (FOREACH ←element:of:set1 IN ←set1
37600 DO UNTIL ←until:condition
37700 (COMPARE:1 ←element:of:set1 ←set2)
37800 ) )))
37900 This can be instantiated in our present context as:
38000 (DEFINEQ COMPARE:1:2:2 (LAMBDA (SET:OF:NO:RELATIONS SET:OF:RELATIONS)
38100 (FOREACH:1:2:2 NO:RELATION IN SET:OF:NO:RELATIONS
38200 DO UNTIL (CONTRADICTS:2 NO:RELATION SET:OF:RELATIONS)
38300 (COMPARE:1:2:2:1 NO:RELATION SET:OF:RELATIONS) ) )))
38400 By convention, when we terminate a foreach loop because of an
38500 UNTIL, the value of the loop is NIL. Otherwise, the value is the
38600 one returned by the final call of the function, in this case
38700 COMPARE:1:2:2:1. We look at the purpose of COMPARE:1:2:2 and realize
38800 all we want to know is whether or not we terminated with a
38900 contradicts. Thus we tentatively define COMPARE:1:2:2:1 as T.
39000
39100 COMMENT
39200 The above discussion is formalized, asserted, and commented.
39300 end of COMMENT
39400
39500 end of ENCODE
39600
39700 end of ADAPT:PRECONCEIVED:FUNCTION
39800
39900 Back in REPEATEDLY. We plunge on.
40000
40100 ADAPT:PRECONCEIVED:FUNCTION
40200
40300 CHOOSE
40400
40500 REPEATEDLY
40600
40700 GENERATE
40800 COMPARE:1:1
40900 end of GENERATE
41000
41100 COMPARE
41200 end of COMPARE
41300
41400 GENERATE
41500 COMPARE:1:2:3
41600 end of GENERATE
41700
41800 COMPARE
41900 We prefer this for the reasons we preferred COMPARE:1:2:1 and
42000 COMPARE:1:2:2 previously.
42100 end of COMPARE
42200
42300 GENERATE
42400 Produces FOREACH.
42500 end of GENERATE
42600
42700 COMPARE
42800 As before, we defer FOREACH in lieu of its innards.
42900 end of COMPARE
43000
43100 GENERATE
43200 Produces FOREACH:1:2:1
43300 end of GENERATE
43400
43500 COMPARE
43600 This is really a tossup, so suppose we pick a comparison over
43700 a foreach loop when we can't otherwise decide.
43800 end of COMPARE
43900
44000 GENERATE
44100 Produces FOREACH:1:2:2
44200 end of GENREATE
44300
44400 COMPARE
44500 Again we defer the foreach in favor of the compare.
44600 end of COMPARE
44700
44800 GENERATE
44900 fails
45000 end of GENERATE
45100
45200 end of REPEATEDLY
45300
45400 end of CHOOSE
45500
45600 So we are going to adapt COMPARE in the call
45700 (COMPARE:1:2:3 SET:OF:MAYBE:RELATIONS SET:OF:RELATIONS) in COMPARE:1:2,
45800 in COMPARE:1.
45900
46000 ENCODE
46100 We create a new context and pick the schema:
46200 (DEFINEQ (COMPARE (LAMBDA (←set1 ←set2)
46300 (FOREACH ←element:of:set1 IN ←set1
46400 DO UNTIL ←until:condition
46500 (COMPARE:1 ←element:of:set1 ←set2)
46600 ) )))
46700 This can be instantiated in our present context as:
46800 (DEFINEQ COMPARE:1:2:3 (LAMBDA (SET:OF:MAYBE:RELATIONS SET:OF:RELATIONS)
46900 (FOREACH:1:2:3 MAYBE:RELATION IN SET:OF:MAYBE:RELATIONS
47000 DO UNTIL (CONTRADICTS:3 MAYBE:RELATION SET:OF:RELATIONS)
47100 (COMPARE:1:2:3:1 MAYBE:RELATION SET:OF:RELATIONS) ) )))
47200 By convention, when we terminate a foreach loop because of an
47300 UNTIL, the value of the loop is NIL. Otherwise, the value is the
47400 one returned by the final call of the function, in this case
47500 COMPARE:1:2:3:1. We look at the purpose of COMPARE:1:2:3 and realize
47600 all we want to know is whether or not we terminated with a
47700 contradicts. Thus we tentatively define COMPARE:1:2:3:1 as T.
47800
47900 COMMENT
48000 The above discussion is formalized, asserted, and commented.
48100 In addition, since we know that CONTRADICTS:3 is currently
48200 always NIL, we add the comment that if this continues until the end,
48300 then the entire COMPARE:1:2:3 function will always return the final
48400 value of COMPARE:1:2:3:1, and this means that -- at present --
48500 COMPARE:1:2:3 always returns the value T. We look where it is used, and
48600 observe that as things now stand, we can eliminate all mention of this
48700 function COMPARE:1:2:3.
48800 end of COMMENT
48900
49000 end of ENCODE
49100
49200 end of ADAPT:PRECONCEIVED:FUNCTION
00100
00200 Back in REPEATEDLY. We plunge on.
00300
00400 ADAPT:PRECONCEIVED:FUNCTION
00500
00600 CHOOSE
00700
00800 REPEATEDLY
00900
01000 GENERATE
01100 Produces FOREACH
01200 end of GENERATE
01300
01400 COMPARE
01500 Picks FOREACH of course
01600 end of COMPARE
01700
01800 GENERATE
01900 Produces FOREACH:1:2:1
02000 end of GENERATE
02100
02200 COMPARE
02300 As before, we pick something "inside" a foreach whenever
02400 possible. Thus we pick FOREACH:1:2:1 over FOREACH.
02500 end of COMPARE
02600
02700 GENERATE
02800 Produces FOREACH:1:2:2
02900 end of GENERATE
03000
03100 COMPARE
03200 A tossup; we stick with our old choice.
03300 end of COMPARE
03400
03500 GENERATE
03600 Produces FOREACH:1:2:3
03700 end of GENERATE
03800
03900 COMPARE
04000 A tossup; we stick with our old choice.
04100 end of COMPARE
04200
04300 GENERATE
04400 COMPARE:1:1
04500 end of GENERATE
04600
04700 COMPARE
04800 As before, we want to defer this until all parts of
04900 COMPARE:1:2 are completed. This includes FOREACH:1:2:1.
05000 end of COMPARE
05100
05200 GENERATE
05300 fails
05400 end of GENERATE
05500
05600 end of REPEATEDLY
05700
05800 end of CHOOSE
05900
06000 So we are going to adapt a foreach loop, FOREACH:1:2:1.
06100
06200 ENCODE
06300 We create a new context. The first thing FOREACH does is to
06400 assert that some initializations be made. Then it tries to decide:
06500
06600 TYPE
06700 There are two flavors of FOREACH:
06800 (22) The two known meanings of a foreach loop are:
06900 (a) DO some operation on each element of a set, terminate when all
07000 elements have been operated on.
07100 (b) DO some operation on some elements of a set, terminate when
07200 an UNTIL condition becomes true, terminate when a WHILE
07300 condition becomes false, terminate when all elements of the set
07400 have been exhausted.
07500 Affect: Which template to use. Also, if type (a), then perhaps
07600 we can use a MAPCAR in its stead; if of second type, maybe we can
07700 use an AND in its place.
07800
07900 end of TYPE
08000
08100 So ENCODE realizes it must tackle this problem first.
08200
08300 OBEY:DEMON (RESOLVE:DECISION)
08400 Since an UNTIL is present in the call to FOREACH:1:2:1, we
08500 assume that it is of type (b). The comments about (b) tell us that
08600 unless indicated otherwise, the FOREACH loop will have value NIL if
08700 we terminate via the UNTIL, and otherwise will have the value of
08800 the operation on the final element of the set.
08900 end of OBEY:DEMON (RESOLVE:DECISION)
09000
09100 So the template we pick is
09200 (DEFINEQ (FOREACH (LAMBDA (←element IN ←set DO UNTIL ←until:condition
09300 (←operation ←←fixed:args1 ←element ←←fixed:args2))
09400 (COND ((NULL ←set) T))
09500 (PROG (←result)
09600 ←label
09700 (SETQ ←element (CAR ←set))
09800 (SETQ ←set (CDR ←set))
09900 (SETQ ←result (←operation ←←fixed:args1 ←element ←←fixed:args2))
10000 (COND (←until:condition (RETURN NIL))
10100 (←set (GO ←label))
10200 (T (RETURN ←result))
10300 )
10400 )
10500 )))
10600 This is easily instantiated, after getting names for ←result and
10700 ←label. But plausible names are generated using the tail part of
10800 the FOREACH name: namely ":1:2:1". I will skip the GET:NAME calls,
10900 because they don't bother the user (these are dummy variables).
11000
11100 (DEFINEQ (FOREACH:1:2:1 (LAMBDA (YES:RELATION IN SET:OF:YES:RELATIONS
11200 DO UNTIL (CONTRADICTS:1 YES:RELATION SET:OF:RELATIONS)
11300 (COMPARE:1:2:1:1 YES:RELATION SET:OF:RELATIONS) )
11400 (COND ((NULL SET:OF:YES:RELATIONS) T)
11500 (PROG (RESULT:1:2:1)
11600 LABEL:1:2:1
11700 (SETQ YES:RELATION (CAR SET:OF:YES:RELATIONS))
11800 (SETQ SET:OF:YES:RELATIONS (CDR SET:OF:YES:RELATIONS))
11900 (SETQ RESULT:1:2:1 (COMPARE:1:2:1:1 YES:RELATION SET:OF:RELATIONS))
12000 (COND ((CONTRADICTS:1 YES:RELATION SET:OF:RELATIONS) (RETURN NIL))
12100 (SET:OF:YES:RELATIONS (GO LABEL:1:2:1))
12200 (T (RETURN RESULT:1:2:1))
12300 )))))
12400 We eval and assert this definition.
12500 In addition, the schema used is preserved.
12600 Later on, we may define another FOREACH the same way. In that event, we
12700 would "generalize" the names of some of the arguments and have both calls
12800 be to the same function. This won't be done until we are sure that they
12900 shall remain the same: something we can't know till near the end of our
13000 task.
13100
13200 COMMENT
13300 Appropriate comments to this affect are tacked on, as are
13400 specifications for initialization of some of the arguments: in particular,
13500 IN, DO, UNTIL. These must be bound, although it is not crucial what
13600 their value is.
13700 Although it probably won't apply in this situation, we see that our choice of
13800 a type (b) FOREACH loop indicates that it might be replaced by an AND.
13900 end of COMMENT
14000
14100 end of ENCODE
14200
14300 end of ADAPT:PRECONCEIVED:FUNCTION
14400
14500
14600 Back in REPEATEDLY. We plunge on.
14700
14800 ADAPT:PRECONCEIVED:FUNCTION
14900
15000 CHOOSE
15100
15200 REPEATEDLY
15300
15400 GENERATE
15500 Produces FOREACH
15600 end of GENERATE
15700
15800 COMPARE
15900 Picks FOREACH of course
16000 end of COMPARE
16100
16200 GENERATE
16300 Produces FOREACH:1:2:2
16400 end of GENERATE
16500
16600 COMPARE
16700 As before, we pick something "inside" a foreach whenever
16800 possible. Thus we pick FOREACH:1:2:2 over FOREACH.
16900 end of COMPARE
17000
17100 GENERATE
17200 Produces FOREACH:1:2:3
17300 end of GENERATE
17400
17500 COMPARE
17600 A tossup; we stick with our old choice.
17700 end of COMPARE
17800
17900 GENERATE
18000 COMPARE:1:1
18100 end of GENERATE
18200
18300 COMPARE
18400 As before, we want to defer this until all parts of
18500 COMPARE:1:2 are completed. This includes FOREACH:1:2:2.
18600 end of COMPARE
18700
18800 GENERATE
18900 fails
19000 end of GENERATE
19100
19200 end of REPEATEDLY
19300
19400 end of CHOOSE
19500
19600 So we are going to adapt a foreach loop, FOREACH:1:2:2.
19700
19800 ENCODE
19900 We create a new context. The first thing FOREACH does is to
20000 assert that some initializations be made. Then it tries to decide:
20100 We recall decision (22) and needn't call TYPE again at this time.
20200 So ENCODE realizes it must tackle this problem first.
20300
20400 OBEY:DEMON (RESOLVE:DECISION)
20500 Since an UNTIL is present in the call to FOREACH:1:2:2, we
20600 assume that it is of type (b). The comments about (b) tell us that
20700 unless indicated otherwise, the FOREACH loop will have value NIL if
20800 we terminate via the UNTIL, and otherwise will have the value of
20900 the operation on the final element of the set.
21000 end of OBEY:DEMON (RESOLVE:DECISION)
21100
21200 So the template we pick is
21300 (DEFINEQ (FOREACH (LAMBDA (←element IN ←set DO UNTIL ←until:condition
21400 (←operation ←←fixed:args1 ←element ←←fixed:args2))
21500 (COND ((NULL ←set) T))
21600 (PROG (←result)
21700 ←label
21800 (SETQ ←element (CAR ←set))
21900 (SETQ ←set (CDR ←set))
22000 (SETQ ←result (←operation ←←fixed:args1 ←element ←←fixed:args2))
22100 (COND (←until:condition (RETURN NIL))
22200 (←set (GO ←label))
22300 (T (RETURN ←result))
22400 )
22500 )
22600 )))
22700 This is easily instantiated, after getting names for ←result and
22800 ←label. But plausible names are generated using the tail part of
22900 the FOREACH name: namely ":1:2:2". I will skip the GET:NAME calls,
23000 because they don't bother the user (these are dummy variables).
23100
23200 (DEFINEQ (FOREACH:1:2:2 (LAMBDA (NO:RELATION IN SET:OF:NO:RELATIONS
23300 DO UNTIL (CONTRADICTS:2 NO:RELATION SET:OF:RELATIONS)
23400 (COMPARE:1:2:2:1 NO:RELATION SET:OF:RELATIONS) )
23500 (COND ((NULL SET:OF:NO:RELATIONS) T)
23600 (PROG (RESULT:1:2:2)
23700 LABEL:1:2:2
23800 (SETQ NO:RELATION (CAR SET:OF:NO:RELATIONS))
23900 (SETQ SET:OF:NO:RELATIONS (CDR SET:OF:NO:RELATIONS))
24000 (SETQ RESULT:1:2:2 (COMPARE:1:2:2:1 NO:RELATION SET:OF:RELATIONS))
24100 (COND ((CONTRADICTS:2 NO:RELATION SET:OF:RELATIONS) (RETURN NIL))
24200 (SET:OF:NO:RELATIONS (GO LABEL:1:2:2))
24300 (T (RETURN RESULT:1:2:2))
24400 )))))
24500 We eval and assert this definition.
24600 In addition, the schema used is preserved. Note that it is the same schema
24700 that we used for FOREACH:1:2:1. This is not surprising.
24800 Later on, we may define another FOREACH the same way. In that event, we
24900 would "generalize" the names of some of the arguments and have both calls
25000 be to the same function. This won't be done until we are sure that they
25100 shall remain the same: something we can't know till near the end of our
25200 task. At that time we will merge the FOREACH'S into one: note that they
25300 are actually identical, differing only in names of arguments and dummy
25400 variables.
25500
25600 COMMENT
25700 Appropriate comments to this affect are tacked on, as are
25800 specifications for initialization of some of the arguments: in particular,
25900 IN, DO, UNTIL. These must be bound, although it is not crucial what
26000 their value is.
26100 end of COMMENT
26200
26300 end of ENCODE
26400
26500 end of ADAPT:PRECONCEIVED:FUNCTION
26600
26700 Back in REPEATEDLY. We plunge on.
26800
26900 ADAPT:PRECONCEIVED:FUNCTION
27000
27100 CHOOSE
27200
27300 REPEATEDLY
27400
27500 GENERATE
27600 Produces FOREACH
27700 end of GENERATE
27800
27900 COMPARE
28000 Picks FOREACH of course
28100 end of COMPARE
28200
28300 GENERATE
28400 Produces FOREACH:1:2:3
28500 end of GENERATE
28600
28700 COMPARE
28800 As before, we pick something "inside" a foreach whenever
28900 possible. Thus we pick FOREACH:1:2:3 over FOREACH.
29000 end of COMPARE
29100
29200 GENERATE
29300 COMPARE:1:1
29400 end of GENERATE
29500
29600 COMPARE
29700 As before, we want to defer this until all parts of
29800 COMPARE:1:2 are completed. This includes FOREACH:1:2:3.
29900 end of COMPARE
30000
30100 GENERATE
30200 fails
30300 end of GENERATE
30400
30500 end of REPEATEDLY
30600
30700 end of CHOOSE
30800
30900 So we are going to adapt a foreach loop, FOREACH:1:2:3.
31000
31100 ENCODE
31200 We create a new context. The first thing FOREACH does is to
31300 assert that some initializations be made. Then it tries to decide:
31400 We recall decision (22) and needn't call TYPE again at this time.
31500 So ENCODE realizes it must tackle this problem first.
31600
31700 OBEY:DEMON (RESOLVE:DECISION)
31800 Since an UNTIL is present in the call to FOREACH:1:2:3, we
31900 assume that it is of type (b). The comments about (b) tell us that
32000 unless indicated otherwise, the FOREACH loop will have value NIL if
32100 we terminate via the UNTIL, and otherwise will have the value of
32200 the operation on the final element of the set.
32300 end of OBEY:DEMON (RESOLVE:DECISION)
32400
32500 So the template we pick is
32600 (DEFINEQ (FOREACH (LAMBDA (←element IN ←set DO UNTIL ←until:condition
32700 (←operation ←←fixed:args1 ←element ←←fixed:args2))
32800 (COND ((NULL ←set) T))
32900 (PROG (←result)
33000 ←label
33100 (SETQ ←element (CAR ←set))
33200 (SETQ ←set (CDR ←set))
33300 (SETQ ←result (←operation ←←fixed:args1 ←element ←←fixed:args2))
33400 (COND (←until:condition (RETURN NIL))
33500 (←set (GO ←label))
33600 (T (RETURN ←result))
33700 )
33800 )
33900 )))
34000 This is easily instantiated, after getting names for ←result and
34100 ←label. But plausible names are generated using the tail part of
34200 the FOREACH name: namely ":1:2:3". I will skip the GET:NAME calls,
34300 because they don't bother the user (these are dummy variables).
34400
34500 (DEFINEQ (FOREACH:1:2:3 (LAMBDA (MAYBE:RELATION IN SET:OF:MAYBE:RELATIONS
34600 DO UNTIL (CONTRADICTS:3 MAYBE:RELATION SET:OF:RELATIONS)
34700 (COMPARE:1:2:3:1 MAYBE:RELATION SET:OF:RELATIONS) )
34800 (COND ((NULL SET:OF:MAYBE:RELATIONS) T)
34900 (PROG (RESULT:1:2:3)
35000 LABEL:1:2:3
35100 (SETQ MAYBE:RELATION (CAR SET:OF:MAYBE:RELATIONS))
35200 (SETQ SET:OF:MAYBE:RELATIONS (CDR SET:OF:MAYBE:RELATIONS))
35300 (SETQ RESULT:1:2:3 (COMPARE:1:2:3:1 MAYBE:RELATION SET:OF:RELATIONS))
35400 (COND ((CONTRADICTS:3 MAYBE:RELATION SET:OF:RELATIONS) (RETURN NIL))
35500 (SET:OF:MAYBE:RELATIONS (GO LABEL:1:2:3))
35600 (T (RETURN RESULT:1:2:3))
35700 )))))
35800 We eval and assert this definition.
35900 In addition, the schema used is preserved. Note that it is the same schema
36000 that we used for FOREACH:1:2:1 and FOREACH:1:2:2. This is not surprising.
36100 Later on, we may define another FOREACH the same way. In that event, we
36200 would "generalize" the names of some of the arguments and have both calls
36300 be to the same function. This won't be done until we are sure that they
36400 shall remain the same: something we can't know till near the end of our
36500 task. At that time we will merge the FOREACH'S into one: note that they
36600 are actually identical, differing only in names of arguments and dummy
36700 variables.
36800
36900 COMMENT
37000 Appropriate comments to this affect are tacked on, as are
37100 specifications for initialization of some of the arguments: in particular,
37200 IN, DO, UNTIL. These must be bound, although it is not crucial what
37300 their value is.
37400 end of COMMENT
37500
37600 end of ENCODE
37700
37800 end of ADAPT:PRECONCEIVED:FUNCTION
37900
38000 Back in REPEATEDLY. We plunge on.
38100
38200 ADAPT:PRECONCEIVED:FUNCTION
38300
38400 CHOOSE
38500
38600 REPEATEDLY
38700
38800 GENERATE
38900 Produces FOREACH
39000 end of GENERATE
39100
39200 COMPARE
39300 Picks FOREACH of course
39400 end of COMPARE
39500
39600 GENERATE
39700 COMPARE:1:1
39800 end of GENERATE
39900
40000 COMPARE
40100 As before, we want to defer this until all parts of
40200 COMPARE:1:2 are completed. But this is complete now. So we pick
40300 COMPARE:1:1 as our current best choice, since it is inside FOREACH.
40400 end of COMPARE
40500
40600 GENERATE
40700 fails
40800 end of GENERATE
40900
41000 end of REPEATEDLY
41100
41200 end of CHOOSE
41300
41400 So we are going to adapt COMPARE, in the call
41500 (COMPARE:1:1 LIST:OF:OBJECTS:OF:POSSIBLE:CLASS LIST:OB:OBJECTS:OF:ELEMENT)
41600 which is in COMPARE:1, in TEST:1, in DETERMINE:1, in PARTITION:A:DOMAIN.
41700
41800 ENCODE
41900 We have no WHY part: no reason to compare these two lists, other
42000 than that they are corresponding parts of POSSIBLE:CLASS:NAME and ELEMENT.
42100 So we don't do anything yet, we merely define COMPARE:1:1 as
42200 the constant function T.
42300
42400 COMMENT
42500 We assert, and tack on, that if we ever get a reason to compare
42600 these two lists, this is where to do it. Ditto for any pre-processing
42700 that need be done. These are demonized as well.
42800 end of COMMENT
42900
43000 end of ENCODE
43100
43200 end of ADAPT:PRECONCEIVED:FUNCTION
43300
43400 CHOOSE
43500
43600 REPEATEDLY
43700
43800 GENERATE
43900 Produces FOREACH
44000 end of GENERATE
44100
44200 COMPARE
44300 trivially, FOREACH
44400 end of COMPARE
44500
44600 GENERATE
44700 Fails
44800 end of GENERATE
44900
45000 end of REPEATEDLY
45100
45200 end of CHOOSE
45300
45400 So finally we are going to do the outermost FOREACH, the one
45500 in DETERMINE:1. We refresh our memories of decision (22), and go on.
45600
45700 OBEY:DEMON (RESOLVE:DECISION)
45800 Since no UNTIL or WHILE clause is present in the initial
45900 call to FOREACH, we cannot be sure whether or not it is of type (b).
46000 That is, we are unsure whether to terminate only after exhausting all
46100 elements of LIST:OF:POSSIBLE:CLASS:NAMES, or whether some condition being
46200 true is enough to stop us.
46300
46400 MESSAGE
46500 "Pup: Must I go through each POSSIBLE:CLASS:NAME in
46600 LIST:OF:POSSIBLE:CLASS:NAMES, testing each one? If not, when can
46700 I stop?"
46800 end of MESSAGE
46900
47000 Say user types "Stop after first successful test".
47100
47200 OBTAIN:USABLE:INFORMATION
47300
47400 TRANSLATE
47500
47600 REPEATEDLY
47700
47800 PARSE
47900 (Stop after first) (succesful) (test)
48000 end of PARSE
48100
48200 LOOKUP
48300 (stop after first) becomes UNTIL
48400 end of LOOKUP
48500
48600 LOOKUP
48700 (successful) becomes the function composition
48800 NOT NULL applied to the succeeding piece.
48900 end of LOOKUP
49000
49100 LOOKUP
49200 (test) is recognized in this context as TEST:1.
49300 end of LOOKUP
49400
49500 end of REPEATEDLY
49600
49700 end of TRANSLATE
49800
49900 end of OBTAIN:USABLE:INFORMATION
50000
50100 So we have now:
50200 (UNTIL (NOT (NULL result:of:TEST:1)))
50300 This settles our decision, since it is clearly a (b) form of FOREACH.
50400 end of OBEY:DEMON (RESOLVE:DECISION)
50500
50600 We now feel up to coding the function.
50700
50800 ENCODE
50900 We create a new context, assert that initializations must be
51000 done, rename FOREACH -- say to FOREACH:1 -- and pick a template.
51100 So the template we pick is
51200 (DEFINEQ (FOREACH (LAMBDA (←element IN ←set DO UNTIL ←until:condition
51300 (←operation ←←fixed:args1 ←element ←←fixed:args2))
51400 (COND ((NULL ←set) T))
51500 (PROG (←result)
51600 ←label
51700 (SETQ ←element (CAR ←set))
51800 (SETQ ←set (CDR ←set))
51900 (SETQ ←result (←operation ←←fixed:args1 ←element ←←fixed:args2))
52000 (COND (←until:condition (RETURN NIL))
52100 (←set (GO ←label))
52200 (T (RETURN ←result))
52300 )
52400 )
52500 )))
52600 This is easily instantiated, after getting names for ←result and
52700 ←label. But plausible names are generated using the tail part of
52800 the FOREACH name: namely ":1". I will skip the GET:NAME calls,
52900 because they don't bother the user (these are dummy variables).
53000
53100 (DEFINEQ (FOREACH:1 (LAMBDA
53200 (POSSIBLE:CLASS:NAME IN LIST:OF:POSSIBLE:CLASS:NAMES
53300 DO (TEST:1 POSSIBLE:CLASS:NAME) )
53400 (COND ((NULL LIST:OF:POSSIBLE:CLASS:NAMES) T)
53500 (PROG (RESULT:1)
53600 LABEL:1
53700 (SETQ POSSIBLE:CLASS:NAME (CAR LIST:OF:POSSIBLE:CLASS:NAMES))
53800 (SETQ LIST:OF:POSSIBLE:CLASS:NAMES (CDR LIST:OF:POSSIBLE:CLASS:NAMES))
53900 (SETQ RESULT:1 (TEST:1 POSSIBLE:CLASS:NAME) )
54000 (COND ((NOT (NULL result:of:TEST:1)) (RETURN NIL))
54100 (LIST:OF:POSSIBLE:CLASS:NAMES (GO LABEL:1))
54200 (T (RETURN RESULT:1))
54300 )))))
54400 It is clear that result:of:TEST:1 is -- or will have to be -- the left
54500 side of an assignment to the call to TEST:1. But this is just RESULT:1.
54600 We look at what this function is supposed to return. It should
54700 return a CLASS:NAME if one TESTs positively, and something else otherwise.
54800 As it is now written, this returns NIL if TEST is successful,
54900 and returns the result of the test --
55000 namely NIL -- if the test is unsuccessful. We must change the first
55100 return from NIL to the argument of the successful test: namely
55200 POSSIBLE:CLASS:NAME. The second return, which will always be
55300 NIL if taken, may or may not be OK as it is. This is something we must
55400 determine now. We see that FOREACH:1 must return what DETERMINE:1 must
55500 return: a class name. But if no class name in the
55600 LIST:OF:POSSIBLE:CLASS:NAMES tests positively, then which name should
55700 we return? Clearly, it is not OK just to return the last name tried,
55800 for otherwise how could we know whether or not we returned it with
55900 success or failure? One solution, using programming knowledge, is to
56000 make the final element of LIST:OF:CLASS:NAMES a distinguished entry, one
56100 guaranteed to fail always. Then, by returning that final element, we
56200 wiould convey failure; by returning any other, we would signify success.
56300 This is too uncertain to be undertaken without confirmation.
56400
56500 MESSAGE
56600 "Pup: If ELEMENT contradicts every possible class name,
56700 what class name do I use? My suggestion is to have a distinguished
56800 class name, say FAILURE, which will be returned in that case."
56900 end of MESSAGE
57000
57100 Say user types "Ask me for the correct class name".
57200 We cannot use this as it is.
57300
57400 OBTAIN:USABLE:INFORMATION
57500
57600 TRANSLATE
57700
57800 REPEATEDLY
57900
58000 PARSE
58100 (Ask me for the) ((correct (class name))
58200 end of PARSE
58300
58400 LOOKUP
58500 (ask me for the) is translated as the known function
58600 (ASK:FOR), which prints a question and receives the reply. It takes the
58700 next piece as its one argument.
58800 end of LOOKUP
58900
59000 LOOKUP
59100 (correct (class name)) becomes CLASS:NAME, with the note
59200 that we are certain it is right. We also note that in addtion -- or instead
59300 -- we may have to create a new variable to hold this, distinct from
59400 CLASS:NAME.
59500 end of LOOKUP
59600
59700 end of REPEATEDLY
59800
59900 end of TRANSLATE
60000
60100 end of OBTAIN:USABLE:INFORMATION
60200
60300 We thus change the second return from (RETURN RESULT:1) to
60400 (RETURN (ASK:FOR CLASS:NAME)).
60500 We notice that the null test for LIST:OF:POSSIBLE:CLASS:NAMES is the same;
60600 if the list is null then we must ask what name to return. We therefore
60700 replace the T at the end of this check by (RETURN (ASK:FOR CLASS:NAME)).
60800 We are through with the definition.
60900 We eval and assert this definition.
61000 In addition, the schema used is preserved.
61100 Later on, we may define another FOREACH the same way. In that event, we
61200 would "generalize" the names of some of the arguments and have both calls
61300 be to the same function. This won't be done until we are sure that they
61400 shall remain the same: something we can't know till near the end of our
61500 task. Note that this is slightly different from the previous FOREACH's,
61600 since the UNTIL condition is implicit, not an argument.
61700
61800 COMMENT
61900 Appropriate comments to this affect are tacked on, as are
62000 specifications for initialization of some of the arguments: in particular,
62100 IN, DO. These must be bound, although it is not crucial what
62200 their value is.
62300 end of COMMENT
62400
62500 end of ENCODE
62600
62700 end of ADAPT:PRECONCEIVED:FUNCTION
62800
62900 Back in the REPEATEDLY loop, we see CF isn't done yet.
63000
63100 ADAPT:PRECONCEIVED:FUNCTION
63200
63300 CHOOSE
63400
63500 REPEATEDLY
63600
63700 GENERATE
63800 Produces ASK:FOR
63900 end of GENERATE
64000
64100 COMPARE
64200 end of COMPARE
64300
64400 GENERATE
64500 end of GENERATE
64600
64700 end of REPEATEDLY
64800
64900 end of CHOOSE
65000
65100 We can immediately encode this simple function.
65200
65300 ENCODE
65400 We create a new context, replace ASK:FOR by ASK:FOR:1,
65500 and pick the schema for ASK:FOR:
65600 (DEFINEQ (ASKFOR (LAMBDA (←arg)
65700 (PRIN1 (QUOTE "PLEASE GIVE ME "))
65800 (PRINT arg)
65900 (SETQ arg (READ))
66000 )))
66100 We know that the argument is "CLASS:NAME". Our programming knowledge
66200 about eval tells us that we should have quoted it, since we want
66300 CLASS:NAME reset. The way it stands, if the value of class name is x,
66400 then x would get reset by ASK:FOR. So we change the call to
66500 (ASKFOR (QUOTE CLASS:NAME)), and substitute CLASS:NAME for ←arg.
66600 This puts an end to our task. We add a few comments and leave.
66700 end of ENCODE
66800
66900 end of ADAPT:PRECONCEIVED:FUNCTION
00100
00200 Back in the REPEATEDLY loop of WRITE:PROGRAM, we see
00300 that we have not yet completed code for CF, since no assertion
00400 to that effect exists. However, no undefined function names remain:
00500 neither are there any preconceived functions to adapt.
00600 We next shall worry about those situations we'd previously labelled
00700 improbable (infinite loops) or incorrect (variables not initialized).
00800 triggers several demons who were willing to wait till this situation.
00900
01000 OBEY:DEMON (RESOLVE:DECISION)
01100 One large group of demons is concerned with choosing appropriate
01200 data structures for the entities we have been dealing with. Pup knows
01300 that this must be decided on before all the final little details of the
01400 code are worked over. Say the demon who wakes up first is the one to
01500 worry about the data structure for LIST:OF:POSSIBLE:CLASS:NAMES.
01600
01700 CHOOSE:DATA:STRUCTURE
01800 As a prerequisite, we refresh our memeories about the object.
01900 It is assumed to be a list. Each element of the list is a name of a
02000 POSSIBLE:CLASS. For each such name, there are four associated structures:
02100 the SET:OF:YES:RELATIONS, the SET:OF:NO:RELATIONS, and the
02200 SET:OF:MAYBE:RELATIONS, and finally the LIST:OF:OBJECTS:OF:POSSIBLE:CLASS.
02300 We examine the existing code, and the notes, and see no significant
02400 interaction between these four structures. Our knowledge of programming
02500 tells us that keeping these four objects on the property list of their
02600 corresponding POSSIBLE:CLASS:NAME is quite suitable.
02700 The postrequisite is to set up the structures, or at least to make
02800 demons which will eventually do so. We examine the PROPERTY:LIST being.
02900 We see that to store N entities on a property list, we must get
03000 N associated identifiers. These are usually contractions of the full
03100 name of the entities. Thus armed, we pick reasonable names for identifiers.
03200
03300 GET:NAME
03400
03500 PLAUSIBLE:NAMES
03600 {YES:SET, YES, YES:RELATIONS, ...}
03700 end of PLAUSIBLE:NAMES
03800
03900 Say we choose YES:RELATIONS.
04000 end of GET:NAME
04100
04200 GET:NAME
04300
04400 PLAUSIBLE:NAMES
04500 {NO:SET, NO, NO:RELATIONS, ...}
04600 end of PLAUSIBLE:NAMES
04700
04800 Say we choose NO:RELATIONS.
04900 end of GET:NAME
05000
05100 GET:NAME
05200
05300 PLAUSIBLE:NAMES
05400 {MAYBE:SET, MAYBE, MAYBE:RELATIONS, ...}
05500 end of PLAUSIBLE:NAMES
05600
05700 Say we choose MAYBE:RELATIONS.
05800 end of GET:NAME
05900
06000 GET:NAME
06100
06200 PLAUSIBLE:NAMES
06300 {LIST:OF:OBJECTS, OBJECTS:OF:POSSIBLE:CLASS,
06400 POSSIBLE:CLASS:OBJECTS, POSSIBLE:OBJECTS, CLASS:OBJECTS, OBJECTS}
06500 end of PLAUSIBLE:NAMES
06600
06700 Say we choose CLASS:OBJECTS.
06800 end of GET:NAME
06900
07000 Thus we now know the names of the four properties. We must
07100 demonize initialization, modification, and accession; or implement them
07200 now. Property:list being tells us that to modify we will use something
07300 like (PUT POSSIBLE:CLASS:NAME YES:RELATIONS SET:OF:YES:RELATIONS), to
07400 access we wiml to!so⎇euhi}g!li{e
07500 (SETQ SET:OF:YES:RELATIONS (GET POSSIBLE:CLASS:NAME YES:RELATIONS)).
07600 Similar notes apply to each of the other entities.
07700 The only initialization that needs be done is to the names of the identifiers.
07800 Since LISP requires they be evaluated, we must fix their values
07900 once and for all. Typically, we will set each to (QUOTE itself), for
08000 example we will do (SETQ YES:RELATIONS (QUOTE YES:RELATIONS)) early in
08100 the system, before any call to PUT or GET on an element of
08200 LIST:OF:POSSIBLE:CLASS:NAMES. These demons are more patient than the
08300 one to choose the dat structure: they can wait until there is nothing
08400 else to do before acting. Finally, we must worry about the list
08500 structure LIST:OF:POSSIBLE:CLASS:NAMES itself. We examine the list
08600 being, and see that we must worry about initialization, insertion,
08700 and deletion. Insertion depends crucially on how the list is ordered.
08800 We set up a demon which will eventually determine this ordering. We
08900 must give it a name now.
09000
09100 GET:NAME
09200
09300 PLAUSIBLE:NAMES
09400 {LIST:OF:POSSIBLE:CLASS:NAMES:ORDERING,
09500 POSSIBLE:CLASS:NAMES:ORDERING, CLASS:NAMES:ORDERING, ...}
09600 end of PLAUSIBLE:NAMES
09700
09800 Say we choose CLASS:NAMES:ORDERING
09900 end of GET:NAME
10000
10100 Now we know that to insert is to merge using this ordering.
10200 (SETQ LIST:OF:POSSIBLE:CLASS:NAMES
10300 (MERGE new:possible:class:name
10400 LIST:OF:POSSIBLE:CLASS:NAMES
10500 CLASS:NAMES:ORDERING)
10600 )
10700 We know that to delete we use the standard removal function PULL:OUT
10800 (PULLOUT desired:possible:class:name LIST:OF:POSSIBLE:CLASS:NAMES).
10900 The standard initialization is to NIL, and since we know nothing better
11000 now, we demonize the fact that
11100 (SETQ LIST:OF:POSSIBLE:CLASS:NAMES initial:value) will have to occur
11200 near the beginning of the CF program, and that initial:value is probably
11300 NIL. A few notes are set up in case we discover that what we want is
11400 not a list but rather one of its alternatives (e.g., a class).
11500 We now look over the code we've written, seeing where we have already
11600 a need for some of thee operations. We tentatively stick the initialization
11700 of property names as a separate function, occurring in CF itself,
11800 before the call to PARTITION:A:DOMAIN. We may have other initializations
11900 to be done, so GET:NAME wisely chooses to call it INITIALIZE:1. In fact,
12000 this triggers the demon holding the initializations of IN, DO, UNTIL to
12100 add his to this function. We also put the initialization of
12200 LIST:OF:POSSIBLE:CLASS:NAMES to NIL in this function. We see no insertions
12300 or deletions for this latter variable. Although this means no work for us
12400 now, we do note that it is a highly improbable situation. The first use
12500 of the properties occurs in COMPARE:1, where we assume that we have
12600 gotten LIST:OF:OBJECTS:OF:POSSIBLE:CLASS. We therefore add
12700 (SETQ LIST:OF:OBJECTS:OF:POSSIBLE:CLASS
12800 (GET POSSIBLE:CLASS:NAME CLASS:OBJECTS)) to the beginning of this
12900 function. A similar situation occurs in COMPARE1:2, where we decide to
13000 put (SETQ SET:OF:YES:RELATIONS (GET POSSIBLE:CLASS:NAME YES:RELATIONS)),
13100 and same for NO: and MAYBE: relations. We notice that
13200 POSSIBLE:CLASS:NAME is not an argument to COMPARE1:2, so we add it.
13300 This also affects the call, located in COMPARE:1. Again, we see no place
13400 calling for insertions or deletions. Although this is improbable, the
13500 frequent re-initializations make it not as improbable as the situation
13600 for LIST:OF:POSSIBLE:CLASS:NAMES, which never changes from NIL.
13700 end of CHOOSE:DATA:STRUCTURE
13800
13900 end of OBEY:DEMON
14000
14100 OBEY:DEMON
14200 Say this one is worrying about the structure of ELEMENT.
14300
14400 CHOOSE:DATA:STRUCTURE
14500
14600 We refresh our memory of ELEMENT first.
14700 It is composed of three distinct parts:
14800 (a) the CLASS:NAME, or a "?" indicating the absence of CLASS:NAME.
14900 (b) the LIST:OF:OBJECTS:OF:ELEMENT
15000 (c) the SET:OF:RELATIONS, each a static relation about some of the objects.
15100 As before, we see no significant dynamic interaction between these
15200 parts. This time, however, we see no reason to store any of these;
15300 that is, they are read in, used, and replaced. Whether or not they must
15400 be saved is precisely the question that demon (4) must answer. We add
15500 the note that if they must be saved, we will probably use property
15600 lists. For now, though, we may as well keep them as three distinct
15700 entities.Clearly, (a) is simply an atom; (b) is a list of atoms;
15800 (c) is a list of simple lists, each simple list representing an n-ary
15900 relation (for some n) and thus consisting of an atom (the name) and
16000 n more atoms chosen fromthe list (b). Thus, for (a), we consult the
16100 atom being. We see that initialization and modification are done via
16200 SETQ, and that accessing is done by simply having the atom present.
16300 For (b) we look at the simple list being. For initialization, we
16400 must have a SETQ. For inserting, we will use a merge, dependent upon
16500 the particular ordering being employed.
16600
16700 GET:NAME
16800 As before, say we get the name ELEMENT:OBJECTS:ORDERING.
16900 end of GET:NAME
17000
17100 An insertion will then look like (SETQ LIST:OF:OBJECTS:OF:ELEMENT
17200 (MERGE new:object LIST:OF:OBJECTS:OF:ELEMENT ELEMENT:OBJECTS:ORDERING)).
17300 A deletion uses PULL:OUT as described earlier.
17400 For (c), we similarly arrive at a SETQ for initialization,
17500 (MERGE new:static:relation SET:OF:RELATIONS ELEMENT:RELATIONS:ORDERING)),
17600 for insertion, and PULL:OUT for deletions. In addition, a note is added
17700 warning that this ordering function may be much more complex than the
17800 previous ones, since it compares two lists, not two atoms. We note that
17900 these processes all must occur each time ELEMENT changes; in particular,
18000 the initializations should come soon after (INPUT:1 ELEMENT), if not
18100 during. As before, we add some sundry comments. We examine where
18200 we must initialize. It must be before the call to HAS:NAME; thus it
18300 is before, during, or after INPUT:1. We inspect INPUT:1, and see that
18400 in fact all it does IS to initialize ELEMENT, and the three parts of
18500 ELEMENT. The right hand sides of the latter are not yet definite, but
18600 an assertion tells us not o worry, these are structural functions
18700 (e.g., members of (CAR , CDR)* ) and easily inferred from an example
18800 or two. We notice that the setting of ELEMENT to (READ) forces us
18900 to accept the user's choice of structure for ELEMENT. Programming
19000 knowledge warns us that this may be dangerous, but if it works it
19100 is probably the most natural thing to do. We comment this and go on.
19200 No insertions or deletions are observed, but we aren't too
19300 worried since the parts are re-initialized fairly frequently. We demonize
19400 these last few points, and, since no modification of existing code is
19500 required, we quit.
19600 end of CHOOSE:DATA:STRUCTURE
19700
19800 end of OBEY:DEMON
19900
20000 Back in REPEATEDLY loop of WRITE:PROGRAM. Notice that
20100 OBEY:DEMON is always "in order", even from this high level. But now
20200 we have no unknown data structure demons clamoring for our attention.
20300 We proceed with the choice from {OBTAIN:USABLE:INFORMATION, USE:INFORMATION
20400 FILL:IN:UNDEFINED:SECTION, CLARIFY:IMPROBABLE:SECTION,
20500 FIX:INCORRECT:PIECE}. We immediately discard FILL:IN:UNDEFINED:SECTION
20600 since none exists. We don't have any usable information, so
20700 USE:INFORMATION is also out of the running. We scrutinize the When parts
20800 of the remainder, and make our decision (somewhat arbitrary).
20900
21000 CLARIFY:IMPROBABLE:SECTION
21100 First, we must select what improbability to confront. This is based
21200 on the programming philosophy: choose the section most important to the
21300 program you are writing. For example, an improbable output format takes
21400 a back seat to an improbable algorithm for generating that output.
21500 We have been keeping a class of improbable items, and we now evaluate
21600 each for criteria of importance to the CF system.
21700
21800 CHOOSE:FROM
21900 Clearly, CF hinges around LIST:OF:POSSIBLE:CLASS:NAMES. This
22000 data structure is the key to the concept identification process, it is
22100 the repository of all the permanent knowledge about concepts. We will
22200 work on its improbable points before any others'. In particular, we
22300 noted that it never changes from NIL. This is our improbability.
22400 end of CHOOSE:FROM
22500
22600 The next thing to do is to decide whether this is incorrect or
22700 merely unusual. We know from programming knowledge how to follow
22800 through code. We do so, and discover that FOREACH:1 will always return
22900 (ASK:FOR:1 (QUOTE CLASS:NAME)). Thus CF itself would be trivial,
23000 and we know that no concept formation program is trivial. We thus
23100 make a few assertions to ease the strain if we are wrong, and commit
23200 ourselves to the view that this improbability is actually an error.
23300 Once we know this, we must fix the incorrect piece.
23400
23500 FIX:INCORRECT:PIECE
23600 We try to ask ourselves what is missing. We easily see the
23700 answer: we must insert class names into LIST:OF:POSSIBLE:CLASS:NAMES.
23800 This can be gotten directly from the name of the variable. Now that
23900 we know a procedure has been omitted, we try to find our where we
24000 omitted it. But "where" in a program really means "when" in execution
24100 time. So we ask ourselves when should we insert an entry? Well, a
24200 necessary condition is of course that we have something to insert.
24300 Following this up, we note that this occurs in the current system
24400 whenever we call ASK:FOR (QUOTE CLASS:NAME). Until we hit a snag, we
24500 proceed along this path of reasoning. We assume that just after this
24600 call, we conditionally insert the class name into the list.
24700 This is less sound logically than even abductive logic, but it seems
24800 to work pretty often, so we will not disparage it here. In any event,
24900 we now are prepared to ask the user for an answer.
25000
25100 MESSAGE
25200 "Pup: After I ask you what the correct class name is, I
25300 test it and conditionally insert it into the list of possible class
25400 names. What is that condition?"
25500 end of MESSAGE
25600
25700 Say user types "The condition is that the class name is not
25800 already in the list, and the class name is neither NIL nor NOTHING".
25900
26000 OBTAIN:USABLE:INFORMATION
26100
26200 TRANSLATE
26300
26400 REPEATEDLY
26500
26600 PARSE
26700 (The condition is that) (the class name) (is not already in)
26800 the list) (and) (the class name) (is neither (NIL) nor (NOTHING)).
26900 end of PARSE
27000
27100 LOOKUP
27200 (The condition is) becomes recognized as: the predicate we
27300 asked for is the following.
27400 end of LOOKUP
27500
27600 LOOKUP
27700 (the class name) becomes CLASS:NAME, in fact the correct
27800 class name.
27900 end of LOOKUP
28000
28100 LOOKUP
28200 (is not already in) becomes the composition NOT MEMBER.
28300 end of LOOKUP
28400
28500 LOOKUP
28600 (the list) becomes LIST:OF:POSSIBLE:CLASS:NAMES
28700 end of LOOKUP
28800
28900 LOOKUP
29000 (and) is the known function AND, and it is prefixed.
29100 end of LOOKUP
29200
29300 LOOKUP
29400 (the class name) again is the correct CLASS:NAME
29500 end of LOOKUP
29600
29700 LOOKUP
29800 (is neither ←x nor ←y) is recognized as
29900 (AND (NOT (EQUAL previous:piece ←x)) (NOT (EQUAL previous:piece ←y))).
30000 end of LOOKUP
30100
30200 LOOKUP
30300 (NIL) is recognized as (QUOTE NIL), the fixed atom.
30400 end of LOOKUP
30500
30600 LOOKUP
30700 (NOTHING) is recognized as (QUOTE NOTHING) a constant atom.
30800 end of LOOKUP
30900
31000 end of REPEATEDLY
31100
31200 end of TRANSLATE
31300
31400 end of OBTAIN:USABLE:INFORMATION
31500
31600 We now are reasonably sure that we have part of the solution.
31700 We modify ASK:FOR:1, adding at the end the following conditional:
31800 (COND ((AND (NOT (MEMBER CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES))
31900 (AND (NOT (EQUAL CLASS:NAME (QUOTE NIL)))
32000 (NOT (EQUAL CLASS:NAME (QUOTE NOTHING)))
32100 )
32200 )
32300 (INSERT CLASS:NAME LIST:OF:CLASS:NAMES)
32400 )
32500 ).
32600 This can be simplified, but we won't worry about that now. Notice
32700 that we now have INSERT as a known function which must be adapted.
32800 end of FIX:INCORRECT:PIECE
32900
33000 Before terminating the clarification process, we must explore the
33100 question again, having eliminated the previous path of reasoning. We
33200 again arrive at the point of seeing when we have an entry to insert into
33300 LIST:OF:CLASS:NAMES, and this time we notice that this occurs always
33400 just after INPUT:2 is executed. That is, whenever the element has a class
33500 name supplied with it. As before, we assume that this insertion is
33600 conditional. We do now have a guess as to the condition: the same one we
33700 encountered before. We must ask the user however:
33800
33900 MESSAGE
34000 "Pup: After I read an element, if the element has a class name
34100 supplied with it, I test that class name and conditionally insert it into
34200 the list of possible class names. What is that condition? I suspect it
34300 is that the class name is not already in the list and the class name is
34400 neither NIL nor NOTHING. If I am correct, just answer OK. Otherwise,
34500 please tell me what the condition is."
34600 end of MESSAGE
34700
34800 Say the user types back OK. Then the same COND we added to ASK:FOR:1
34900 is added at the end of INPUT:2, except that we use CLASS:NAME, not
35000 CORRECT:CLASS:NAME.
35100 We again try to find another situation in which we should insert into
35200 LIST:OF:POSSIBLE:CLASS:NAMES. This time we come up empty, though.
35300 end of CLARIFY:IMPROBABLE:SECTION
35400
35500 Back in the REPEATEDLY loop, we see CF isn't complete. However, when
35600 we go to choose a function now, we see there is one preconceived one which
35700 must be adapted.
35800
35900 ADAPT:PRECONCEIVED:FUNCTION
36000 I will skip the choice (generate and compare) since there is only
36100 one candidate: INSERT. (there are two instances of this, but they are
36200 similar and a choice between them is either meaningless or arbitrary)
36300
36400 ENCODE
36500 We create a new context and replace INSERT by INSERT:1. We see
36600 that the first condition to be satisfied is to review the structure of
36700 the object to be inserted and the structure it is to be inserted into.
36800 The CLASS:NAME is an atom; the LIST:OF:POSSIBLE:CLASS:NAMES is a
36900 simple list of atoms.
37000 Next, we see if any structures associated with the object to be inserted
37100 must be set up. We find the answer to be yes, there are three:
37200 the three sets of static relations must be put onto the property list
37300 of CLASS:NAME. This then determines the template we use:
37400 (DEFINEQ (INSERT:1 (LAMBDA (CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES)
37500 (SETQ LIST:OF:POSSIBLE:CLASS:NAMES
37600 (MERGE CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES CLASS:NAMES:ORDERING))
37700 (PUT CLASS:NAME YES:RELATIONS set:of:yes:relations)
37800 (PUT CLASS:NAME NO:RELATIONS set:of:no:relations)
37900 (PUT CLASS:NAME MAYBE:RELATIONS set:of:maybe:relations)
38000 (PUT CLASS:NAME CLASS:OBJECTS list:of:objects)
38100 )))
38200 Pup now must determine what the three sets of relations are. They
38300 must be known at the time; thus they almost certainly are drawn from
38400 SET:OF:RELATIONS, since these are the only ones pertaining to the class
38500 CLASS:NAME. Similarly, the list of objects must be subset of
38600 LIST:OF:OBJECTS:OF:ELEMENT.
38700 Now any relation in SET:OF:RELATIONS has probability p≥0, and so
38800 no relations are put into the set:of:no:relations (no pun intended).
38900 On the other hand, we have no reason even to suspect which relations
39000 should be put into set:of:yes:relations. We defer this, deciding to
39100 put all into set:of:maybe:relations, and later switch some to the
39200 yes: set if and when required to. Thus we replace the first two
39300 sets by NIL and the third by SET:OF:RELATIONS. Finally, we suspect
39400 that all objects will be "seen" by the subject, hence recorded.
39500 In any event, we know of no way to eliminate some but not others,
39600 so we tentatively replace list:of:objects by the entire
39700 LIST:OF:OBJECTS:OF:ELEMENT. This completes the coding of INSERT:1.
39800
39900 COMMENT
40000 We add relevant comments. For example, we have taken care
40100 of insertions for LIST:OF:POSSIBLE:CLASS:NAMES, and also we have taken
40200 care of initialization of the properties YES:RELATIONS, NO:RELATIONS,
40300 MAYBE:RELATIONS, and CLASS:OBJECTS. We now know that we must eventually
40400 define CLASS:NAMES:ORDERING. Before, we weren't sure of this, since
40500 it is possible that no insertions would be made into the list of possible
40600 class names. Of course, this is a detail and doesn't affect very much
40700 of the program; we won't work on it immediately.
40800 end of COMMENT
40900
41000 end of ENCODE
41100
41200 end of ADAPT:PRECONCEIVED:FUNCTION
41300
41400 Back in outermost REPEATEDLY loop. For one line, that is.
41500
41600 ADAPT:PRECONCEIVED:FUNCTION
41700 The choice again must be INSERT. This call is the one at the end
41800 of INPUT:2.
41900
42000 ENCODE
42100 We create a new context and replace INSERT by INSERT:2. We see
42200 that the first condition to be satisfied is to review the structure of
42300 the object to be inserted and the structure it is to be inserted into.
42400 The CLASS:NAME is an atom; the LIST:OF:POSSIBLE:CLASS:NAMES is a
42500 simple list of atoms.
42600 Next, we see if any structures associated with the object to be inserted
42700 must be set up. We find the answer to be yes, there are three:
42800 the three sets of static relations must be put onto the property list
42900 of CLASS:NAME. This then determines the template we use:
43000 (DEFINEQ (INSERT:2 (LAMBDA (CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES)
43100 (SETQ LIST:OF:POSSIBLE:CLASS:NAMES
43200 (MERGE CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES CLASS:NAMES:ORDERING))
43300 (PUT CLASS:NAME YES:RELATIONS set:of:yes:relations)
43400 (PUT CLASS:NAME NO:RELATIONS set:of:no:relations)
43500 (PUT CLASS:NAME MAYBE:RELATIONS set:of:maybe:relations)
43600 (PUT CLASS:NAME CLASS:OBJECTS list:of:objects)
43700 )))
43800 Pup now must determine what the three sets of relations are. They
43900 must be known at the time; thus they almost certainly are drawn from
44000 SET:OF:RELATIONS, since these are the only ones pertaining to the class
44100 CLASS:NAME. Similarly, the list of objects must be subset of
44200 LIST:OF:OBJECTS:OF:ELEMENT.
44300 Now any relation in SET:OF:RELATIONS has probability p≥0, and so
44400 no relations are put into the set:of:no:relations (no pun intended).
44500 On the other hand, we have no reason even to suspect which relations
44600 should be put into set:of:yes:relations. We defer this, deciding to
44700 put all into set:of:maybe:relations, and later switch some to the
44800 yes: set if and when required to. Thus we replace the first two
44900 sets by NIL and the third by SET:OF:RELATIONS. Finally, we suspect
45000 that all objects will be "seen" by the subject, hence recorded.
45100 In any event, we know of no way to eliminate some but not others,
45200 so we tentatively replace list:of:objects by the entire
45300 LIST:OF:OBJECTS:OF:ELEMENT. This completes the coding of INSERT:2.
45400
45500 COMMENT
45600 We add relevant comments. For example, we have taken care
45700 of insertions for LIST:OF:POSSIBLE:CLASS:NAMES, and also we have taken
45800 care of initialization of the properties YES:RELATIONS, NO:RELATIONS,
45900 MAYBE:RELATIONS, and CLASS:OBJECTS. We already knew we must eventually
46000 define CLASS:NAMES:ORDERING. Before, we weren't sure of this, since
46100 it is possible that no insertions would be made into the list of possible
46200 class names. Of course, this is a detail and doesn't affect very much
46300 of the program; we won't work on it immediately.
46400 We note that this function is actually the same as INSERT:1, differing only
46500 in its name. If this persisits till the end of CF, we will trivially
46600 then merge the two functions into one.
46700 end of COMMENT
46800
46900 end of ENCODE
47000
47100 end of ADAPT:PRECONCEIVED:FUNCTION
00100
00200 Back in REPEATEDLY loop of WRITE:PROGRAM.
00300 We are in a similar situation to two cycles back.
00400
00500 CLARIFY:IMPROBABLE:SECTION
00600 Again we look for the improbability lying in the most crucial
00700 place. We find that, similarly to last time, no class name's
00800 YES:RELATIONS or NO:RELATIONS will ever change from NIL.
00900 We think about this. Is it an error? Like before, we see that this
01000 would lead to a collapsing of the need for any structure for
01100 the relations of a class. But we derived the fact of this need from
01200 the user's statements about contradiction. Contradiction isn't meaningful
01300 without a trichotomy, and the trichotomy is trivial if all relations
01400 fall into the MAYBE class always. So this must be an error.
01500 Okay then, when should we insert something into the YES:RELATIONS of a
01600 class? The answer comes from the definition of YES: we must insert
01700 a relation into this set iff its absence from an element forces that element
01800 out of the class. How can we be sure of something like that? Well,
01900 if we see two elements, the first is in the class and the second isn't,
02000 and the only difference between them is that the first has this
02100 relation in its set of relations, wheras the second doesn't, then we
02200 can be sure. In fact this is the only way we can be absolutely sure.
02300 How can we know that a certain element is NOT in the class? Well, one
02400 way would be to be told that fact. But we are only told when we ask,
02500 and we only ask if we can't match successfully, and if the second
02600 element just differs in the MAYBE relations, we will identify it as
02700 the same class as the first, and thus never ask. How can we still
02800 ask? Well, do just that: ask the user what the correct class name is,
02900 even if we can come up with a match. Is this OK? Well, let's ask the
03000 user about it now.
03100
03200 MESSAGE
03300 "Pup: In order for me to know when to transfer a relation from
03400 the MAYBE:RELATIONS to the YES:RELATIONS, I must know when I am wrong
03500 in my guess. I would like to ask you what the correct class name is,
03600 not just if I find no matching class, but even if I do find a match.
03700 If I am wrong, then I may transfer as described above, on the
03800 property list of the incorrect class."
03900 end of MESSAGE
04000
04100 Say user types that this is okay. Then Pup sees it must fix
04200 these things up right away.
04300 In particular, we call on ASK:FOR:1 regardless of the testing results.
04400 Also, we must distinguish between the correct class name and
04500 CLASS:NAME. We first get a name for the former.
04600
04700 GET:NAME
04800
04900 PLAUSIBLE:NAMES
05000 {CORRECT:CLASS:NAME, CORRECT, CORRECT:NAME, CORRECT:CLASS,
05100 CCN, C, CC, CN,...}
05200 end of PLAUSIBLE:NAMES
05300
05400 Say we choose CORRECT:CLASS:NAME, without bothering the user.
05500 end of GET:NAME
05600
05700 Now we use our comments to go over the code we've written,
05800 changing CLASS:NAME into CORRECT:CLASS:NAME where necessary.
05900 We go back to using a special class name, say FAILURE, to represent
06000 failing to find any positive match. This replaces the two returns
06100 of ASK:FOR:1 by returns of (QUOTE FAILURE). We place a new --the only--
06200 call to ASK:FOR:1 at the end of DETERMINE:1, namely
06300 (ASK:FOR:1 (QUOTE CORRECT:CLASS:NAME)). We now must follow this by
06400 -- conditionally -- the transfer of a relation from MAYBE:RELATIONS
06500 to YES:RELATIONS. The condition is known to be: (1) the correct class
06600 name isn't the same as the class name we came up with, and
06700 (2) there is a relation which is a member of the set of
06800 MAYBE:RELATIONS of CLASS:NAME, but is not in SET:OF:RELATIONS of the
06900 element just incorrectly identified.
07000 We are ready to encode this.
07100
07200 ENCODE
07300 We create a new context, and follow the lone call to ASK:FOR:1
07400 by the code:
07500 (COND ((AND (NOT (EQUAL CLASS:NAME CORRECT:CLASS:NAME))
07600 (NOT (NULL (SETDIFFERENCE SET:OF:MAYBE:RELATIONS
07700 SET:OF:RELATIONS))))
07800 (FORSOME element IN (SETDIFFERENCE SET:OF:MAYBE:RELATIONS
07900 SET:OF:RELATIONS)
08000 DO (TRANSFER element FROM SET:OF:MAYBE:RELATIONS
08100 TO SET:OF:YES:RELATIONS))))
08200 We easily pick RELATION as the dummy argument "element" above.
08300
08400 COMMENT
08500 If the setdifference is not a singleton, then we may err in
08600 choosing which relation to transfer. Some type of insurance may need to
08700 be set up at that point in the FORSOME loop. THe TRANSFER is a permanent
08800 type; we transfer not just to the current value of SET:OF:YES:RELATIONS,
08900 but to the place where this set is stored permanently: the property list
09000 of CLASS:NAME.
09100 We also try to see when else we could be in error in our transfer.
09200 Well, if some element lacked a relation currently on the MAYBE list,
09300 in the past that is, we might choose that relation accidentally
09400 to be the one transferred to the YES relations. How might we prevent
09500 this? Well, we could separate the set of maybe relations into two
09600 groups: those which always were present, and those which sometimes
09700 were present and sometimes were absent. Candidates for the transfer
09800 to YES relation status could be drawn only from the first subgroup.
09900 In other words, we are distinguishing between 0<p≤1 and 0<p<1 relations.
10000 We then would have to worry abos from the former group to the latter.
10100 Well, this would occur when we saw an element of the class which lacked
10200 one of these "always was present" relations. This idea will be carried
10300 along, and each place where a change would be required will be noted.
10400 THen, if we later have to implement this, we will know where to stick each
10500 piece of new code. We won't bother the user about whether or not to do this
10600 until near the end of the CF task.
10700 In fact, we cannot even be sure the the current, temporary copies of these
10800 two sets should be replaced. We will create new variables to hold the new
10900 FROM and TO sets, and later decide whether or not these should be the
11000 same as the current names: SET:OF:MAYBE:RELATIONS, SET:OF:RELATIONS.
11100 We note that we are making implicit use of the fact that
11200 the property lists of NIL and NOTHING have no entries under MAYBE:RELATIONS
11300 end of COMMENT
11400
11500 end of ENCODE
11600
11700 end of CLARIFY:IMPROBABLE:SECTION
11800
11900 Back in REPEATEDLY loop.
12000
12100 ADAPT:PRECONCEIVED:FUNCTION
12200
12300 CHOOSE
12400
12500 REPEATEDLY
12600
12700 GENERATE
12800 Produces FORSOME
12900 end of GENERATE
13000
13100 COMPARE
13200 end of COMPARE
13300
13400 GENERATE
13500 Produces TRANSFER
13600 end of GENERATE
13700
13800 COMPARE
13900 Since the transfer is inside the forsome loop, we prefer to
14000 work on it first.
14100 end of COMPARE
14200
14300 GENERATE
14400 fails
14500 end of GENERATE
14600
14700 end of REPEATEDLY
14800
14900 end of CHOOSE
15000
15100 So we will work on TRANSFER.
15200
15300 ENCODE
15400 We create a new context, replace TRANSFER by TRANSFER:1,
15500 and recollect what we know. We are doing a permanent type of transfer,
15600 which means altering the permanent copy of the set we are transferring
15700 into -- if such a copy exists. The element to be transferred is a
15800 relation, a list of atoms. The set we are inserting it into is a class,
15900 each of whose elements is a list of atoms. It is stored permanently
16000 on the property list of CLASS:NAME, under the property YES:RELATIONS.
16100 We must also delete the element from the permanent copy of the FROM
16200 list, if one exists. This is also stored on the property list, under
16300 MAYBE:RELATIONS. Its structure is the same as that of the previous one.
16400 Since we are transferring into a class, we needn't worry about ordering.
16500 We also recall that the two actual arguments -- the temporary, current
16600 names for the FROM and TO sets -- may not in fact be changed. We must
16700 create two new sets which hold the modified lists. Later, we will decide
16800 precisely what is wanted here. If we should have modified the arguments,
16900 well that will be easy to change. If we had done it the other way,
17000 modifying now and having to unmodify later, that is more complicated.
17100 Thus we are ready to choose the proper template of transferring:
17200 (DEFINQ (TRANSFER (LAMBDA (element FROM from:set TO to:set)
17300 (SETQ new:copy:of:to:set (CONS element to:set))
17400 (INSERT element permanent:copy:of:to:set)
17500 (SETQ new:copy:of:from:set (PULL:OUT element from:set))
17600 (DELETE element permanent:copy:of:from:set)
17700 )))
17800 We substitute in SET:OF:MAYBE:RELATIONS for from:set,
17900 SET:OF:YES:RELATIONS for to:set, RELATION for element,
18000 (PROPERTY YES:RELATIONS ON PROPERTY:LIST OF CLASS:NAME) for
18100 permanent:copy:of:to:set, and
18200 (PROPERTY MAYBE:RELATIONS ON PROPERTY:LIST OF CLASS:NAME)
18300 for permanent:copy:of:from:set.
18400 We must get names for the new copies of the FROM and TO sets. Since
18500 these are in some sense dummy names, we don't bother the user. Using
18600 GETNAME and PLAUSIBLE:NAMES we choose NEW:SET:OF:MAYBE:RELATIONS and
18700 NEW:SET:OF:YES:RELATIONS. This completes the code.
18800
18900 COMMENT
19000 We assert various comments, including the fact that this
19100 function expects that element really will be a member of the from:set.
19200 We also mark the new variables' names, so that we can change them later.
19300 This would be necessary if (a) it turned out we were supposed to actually
19400 modify the temporary copies as well as the permanent ones, or (b) if it
19500 turned out we used these new variables frequently, and the user didn't
19600 like how they were named. Notice that both of these are very minor points,
19700 and therefore we don't try to settle this now.
19800 end of COMMENT
19900
20000 We assert and eval the definition.
20100 end of ENCODE
20200
20300 end of ADAPT:PRECONCEIVED:FUNCTION
20400
20500 Back in outermost REPEATEDLY loop again.
20600
20700 ADAPT:PRECONCEIVED:FUNCTION
20800
20900 CHOOSE
21000
21100 REPEATEDLY
21200
21300 GENERATE
21400 Produces FORSOME
21500 end of GENERATE
21600
21700 COMPARE
21800 end of COMPARE
21900
22000 GENERATE
22100 Produces INSERT
22200 end of GENERATE
22300
22400 COMPARE
22500 Since the transfer is inside the forsome loop,
22600 and the insert is inside the transfer, we choose to work on INSERT first.
22700 work on it first.
22800 end of COMPARE
22900
23000 GENERATE
23100 Produces DELETE
23200 end of GENERATE
23300
23400 COMPARE
23500 Since it is at the same level as INSERT, but it comes later in
23600 a series, we decide to defer DELETE until after the insert is done.
23700 end of COMPARE
23800
23900 GENERATE
24000 fails
24100 end of GENERATE
24200
24300 end of REPEATEDLY
24400
24500 end of CHOOSE
24600
24700 So we are going to adapt INSERT. The situation is much simpler
24800 than it was for INSERT:1, since now we have no associated structures
24900 to worry about. We simply must stick RELATION into the property list of
25000 CLASS:NAME, as part of the list stored under property YES:RELATIONS.
25100
25200 ENCODE
25300 We create a new context, and rename INSERT as INSERT:1:1.
25400 We recognize insertion from a property list, and in fact we earlier
25500 worried about just this piece of code. The proper template is easily
25600 found:
25700 (DEFINEQ (INSERT (LAMBDA (element (PROPERTY property:name ON
25800 PROPERTY:LIST OF name))
25900 (PROG (temp)
26000 (SETQ temp (GET name property:name))
26100 (SETQ temp (CONS element temp))
26200 (PUT name property:name temp)
26300 ))))
26400 All the variable names are known and substitutable, except for temp.
26500 This is a dummy temporary variable, so we don't bother the user to
26600 get a name for it.
26700
26800 GET:NAME
26900
27000 PLAUSIBLE:NAMES
27100 {TEMP, TEMPORARY, TEMP:SET:OF:YES:RELATIONS, T, ...}
27200 end of PLAUSIBLE:NAMES
27300
27400 Say we pick TEMPORARY:YES:RELATIONS.
27500 end of GET:NAME
27600
27700 So our code now looks something like this:
27800 (DEFINEQ (INSERT:1:1 (LAMBDA (RELATION (PROPERTY YES:RELATIONS ON
27900 PROPERTY:LIST OF CLASS:NAME))
28000 (PROG (TEMPORARY:YES:RELATIONS)
28100 (SETQ TEMPORARY:YES:RELATIONS (GET CLASS:NAME YES:RELATIONS))
28200 (SETQ TEMPORARY:YES:RELATIONS
28300 (CONS RELATION TEMPORARY:YES:RELATIONS))
28400 (PUT CLASS:NAME YES:RELATIONS TEMPORARY:YES:RELATIONS)
28500 ))))
28600 This completes the coding of the INSERT.
28700
28800 COMMENT
28900 We tack on various comments about what we've done. In
29000 particular, note that we must make ON, PROPERTY, PROPERTY:LIST, OF
29100 all have some value (though their value isn't used, they must
29200 nevertheless be defined as something). This comes under the heading
29300 of global, permanent initialization, and will be taken care of later.
29400 end of COMMENT
29500
29600 end of ENCODE
29700
29800 end of ADAPT:PRECONCEIVED:FUNCTION
29900
30000 Back in outermost REPEATEDLY loop again.
30100
30200 ADAPT:PRECONCEIVED:FUNCTION
30300
30400 CHOOSE
30500
30600 REPEATEDLY
30700
30800 GENERATE
30900 Produces FORSOME
31000 end of GENERATE
31100
31200 COMPARE
31300 end of COMPARE
31400
31500 GENERATE
31600 Produces DELETE
31700 end of GENERATE
31800
31900 COMPARE
32000 Since transfer is inside forsome, and delete is inside
32100 the transfer, we decide to do delete before doing forsome.
32200 end of COMPARE
32300
32400 GENERATE
32500 fails
32600 end of GENERATE
32700
32800 end of REPEATEDLY
32900
33000 end of CHOOSE
33100
33200 So we are going to adapt the preconceived function DELETE.
33300 We simply must pull RELATION out of the property list of CLASS:NAME,
33400 out of the list stored under the property MAYBE:RELATIONS.
33500
33600 ENCODE
33700 We create a new context, and rename DELETE as DELETE:1:1.
33800 We recognize deletion from a property list, and in fact we earlier
33900 worried about just this piece of code. The proper template is easily
34000 found:
34100 (DEFINEQ (DELETE (LAMBDA (element (PROPERTY property:name ON
34200 PROPERTY:LIST OF name))
34300 (PROG (temp)
34400 (SETQ temp (GET name property:name))
34500 (SETQ temp (PULL:OUT element temp))
34600 (PUT name property:name temp)
34700 ))))
34800 All the variable names are known and substitutable, except for temp.
34900 This is a dummy temporary variable, so we don't bother the user to
35000 get a name for it.
35100
35200 GET:NAME
35300
35400 PLAUSIBLE:NAMES
35500 {TEMP, TEMPORARY, TEMP:SET:OF:MAYBE:RELATIONS, T, ...}
35600 end of PLAUSIBLE:NAMES
35700
35800 Say we pick TEMPORARY:MAYBE:RELATIONS.
35900 end of GET:NAME
36000
36100 So our code now looks something like this:
36200 (DEFINEQ (DELETE:1:1 (LAMBDA (RELATION (PROPERTY MAYBE:RELATIONS ON
36300 PROPERTY:LIST OF CLASS:NAME))
36400 (PROG (TEMPORARY:MAYBE:RELATIONS)
36500 (SETQ TEMPORARY:MAYBE:RELATIONS (GET CLASS:NAME MAYBE:RELATIONS))
36600 (SETQ TEMPORARY:MAYBE:RELATIONS
36700 (PULL:OUT RELATION TEMPORARY:MAYBE:RELATIONS))
36800 (PUT CLASS:NAME MAYBE:RELATIONS TEMPORARY:MAYBE:RELATIONS)
36900 ))))
37000 This completes the coding of the DELETE.
37100
37200 COMMENT
37300 We tack on various comments about what we've done. In
37400 particular, note that we must make ON, PROPERTY, PROPERTY:LIST, OF
37500 all have some value (though their value isn't used, they must
37600 nevertheless be defined as something). This comes under the heading
37700 of global, permanent initialization, and will be taken care of later.
37800 We notice that we've made the same note before, so we don't do it again.
37900 end of COMMENT
38000
38100 end of ENCODE
38200
38300 end of ADAPT:PRECONCEIVED:FUNCTION
38400
38500 Back in outermost REPEATEDLY loop again.
38600
38700 ADAPT:PRECONCEIVED:FUNCTION
38800
38900 CHOOSE
39000
39100 REPEATEDLY
39200
39300 GENERATE
39400 Produces FORSOME
39500 end of GENERATE
39600
39700 COMPARE
39800 end of COMPARE
39900
40000 GENERATE
40100 fails
40200 end of GENERATE
40300
40400 end of REPEATEDLY
40500
40600 end of CHOOSE
40700
40800 So we are going to adapt FORSOME. This is typically a simple function
40900 We have a note cautioning us that, unless the set to choose from is a
41000 singleton, we could err in our choice. Thus it is important to decide how to
41100 resolve such a dilemma before coding FORSOME. This is the task of a demon
41200 we created when we put the COND in just after the call to ASK:FOR:1.
41300
41400 OBEY:DEMON (RESOLVE:DECISION)
41500 We don't know any more about this than when we set the demon up.
41600
41700 MESSAGE
41800 "Pup: If there is more than one relation in the MAYBE:RELATIONS
41900 of CLASS:NAME that is also not in the SET:OF:RELATIONS of ELEMENT, how
42000 do I choose which RELATION to transfer from MAYBE:RELATIONS to
42100 YES:RELATIONS?"
42200 end of MESSAGE
42300
42400 Say user types back "Choose randomly".
42500 This is recognized as meaning the question is irrelevant, we can implement
42600 any strategy we choose.
42700 end of OBEY:DEMON
42800
42900 A note is asserted, mentioning that we may in fact err in our
43000 choice. If we do, we might have to back up in some way and choose again.
43100 This would entail storage of the alternatives along with the chosen
43200 relation, on the YES:RELATIONS list. That is, each element of that list
43300 would have a list of alternatives associated with it. This is something
43400 to keep in mind. We won't ask the user until the choice would make a
43500 difference in how we would proceed.
43600
43700 ENCODE
43800 We create a new context, replace FORSOME by FORSOME:1, and look
43900 up what the easiest method of choosing from a set is: if the set is
44000 stored as a LISP list, it is simplest to take the CAR of the list.
44100 We pick the template
44200 (DEFINEQ (FORSOME (LAMBDA (element IN set DO
44300 (action ←←fixed:args element ←←fixed:args2))
44400 (COND ((NULL set) failure:condition))
44500 (SETQ element (CAR set))
44600 (action ←←fixed:args element ←←fixedargs2)
44700 )))
44800 We see that the arguments' names are unimportant, and if the actual
44900 arguments are too complex, we shall replace them by plausible substitiutes.
45000 Thus we arrive at something like:
45100 (DEFINEQ (FORSOME:1 (LAMBDA (RELATION IN SET:DIFF DO (TRANSFER:1 RELATION
45200 FROM SET:OF:MAYBE:RELATIONS TO SET:OF:YES:RELATIONS))
45300 (COND ((NULL SET:DIFF) failure:condition))
45400 (SETQ RELATION (CAR SET:DIFF))
45500 (TRANSFER:1 RELATION FROM SET:OF:MAYBE:RELATIONS
45600 TO SET:OF:YES:RELATIONS)
45700 )))
45800 The only thing left to fill in is what we return if there is no element
45900 to choose; that is, if the setdifference is NIL. Since this function
46000 is being executed for effects rather than value, this is not too
46100 important. We would like it simply to be different than if we succeed.
46200 We therefore substitute NIL for failure:condition, and we add T at the
46300 end of the function definition, that is, if we succeed.
46400 (DEFINEQ (FORSOME:1 (LAMBDA (RELATION IN SET:DIFF DO (TRANSFER:1 RELATION
46500 FROM SET:OF:MAYBE:RELATIONS TO SET:OF:YES:RELATIONS))
46600 (COND ((NULL SET:DIFF) NIL))
46700 (SETQ RELATION (CAR SET:DIFF))
46800 (TRANSFER:1 RELATION FROM SET:OF:MAYBE:RELATIONS
46900 TO SET:OF:YES:RELATIONS)
47000 T
47100 )))
47200 This completes the encoding of FORSOME.
47300
47400 COMMENT
47500 We reaffirm the fact that backtracking may have to be
47600 implemented, and we add the discussion of the method we could use,
47700 as discussed earlier. We add that FORSOME:1 does not require the
47800 set to be non-null, and that a return of T indicates success, NIL
47900 indicates failure. We notice that IN, DO, FROM, TO must be initialized,
48000 but we already have a note to that effect.
48100 end of COMMENT
48200
48300 end of ENCODE
48400
48500 end of ADAPT:PRECONCEIVED:FUNCTION
48600
00100
00200 Back in REPEATEDLY loop of WRITE:PROGRAM.
00300 We are in a similar situation to a few cycles back.
00400
00500 CLARIFY:IMPROBABLE:SECTION
00600 Again we look for the improbability lying in the most crucial
00700 place. We find that, similarly to before, no class name's
00800 NO:RELATIONS will ever change from NIL.
00900 Is this an error? We remember from last time that it is. We don't
01000 have to repeat all the reasoning steps a second time.
01100 Okay then, when should we insert something into the NO:RELATIONS of a
01200 class? The answer comes from the definition of NO: we must insert
01300 a relation into this set iff its presence in an element forces that element
01400 out of the class. How can we be sure of something like that? Well,
01500 if we see two elements, the first is in the class and the second isn't,
01600 and the only difference between them is that the first lacks this
01700 relation in its set of relations, wheras the second doesn't, then we
01800 can be sure. In fact this is the only way we can be absolutely sure.
01900 How can we know that a certain element is NOT in the class? Well, one
02000 way would be to be told that fact. This time, in fact, we see that we
02100 do ask in each case. So that problem is taken care of already for us.
02200 We see that we must follow (ASK:FOR:1 (QUOTE CORRECT:CLASS:NAME))
02300 -- conditionally -- with the transfer of a relation from SET:OF:RELATIONS
02400 of element to NO:RELATIONS. The condition is known to be: (1) the correct
02500 class name isn't the same as the class name we came up with, and
02600 (2) there is a relation which is not a member of the set of
02700 MAYBE:RELATIONS of CLASS:NAME, but is in SET:OF:RELATIONS of the
02800 element just incorrectly identified.
02900 We have a new problem suddenly. This new piece of code should go exactly
03000 where the previous COND associated with transferring to YES:RELATIONS
03100 went. But our knowledge of programming tells us that it must go before
03200 or after. It is also possible that the results of one transfer affect
03300 whether the other transfer is even attempted.
03400
03500 RESOLVE:DECISION
03600 We seek to compare the two tasks. The previous one deals with
03700 using positive information to modify current concepts. The current task
03800 deals with using negative information for the same ends. Pup finds an
03900 assertion that most psychologists believe positive information to be
04000 more valuable; a similar result occurs in searching, where a direct
04100 path is often tried before a search by elimination. Thus Pup suspects that
04200 the existing COND goes before the piece of code about to be written.
04300 But it has no clue as to whether or not to try the NO transfer if the
04400 YES transfer succeeds. It must ask the user.
04500
04600 MESSAGE
04700 "Pup: I assume that I try to transfer from MAYBE:RELATIONS
04800 to YES:RELATIONS before I try to transfer from SET:OF:RELATIONS to
04900 NO:RELATIONS. If the first transfer fails, I assume I try the second
05000 transfer. If the first transfer succeeds, do I still try to do the
05100 second transfer?"
05200 end of MESSAGE
05300
05400 Say user types back No. So the two pieces of code are to be
05500 enclosed in an outermost conditional:
05600 (COND (first:piece T) (T second:piece)).
05700 end of RESOLVE:DECISION
05800
05900 We are ready to encode this second piece of code now.
06000
06100 ENCODE
06200 We create a new context, and follow the lone call to ASK:FOR:1
06300 by the outer cond we wrote above. The second piece of this is:
06400 (COND ((AND (NOT (EQUAL CLASS:NAME CORRECT:CLASS:NAME))
06500 (NOT (NULL (SETDIFFERENCE SET:OF:RELATIONS
06600 SET:OF:MAYBE:RELATIONS))))
06700 (FORSOME element IN (SETDIFFERENCE SET:OF:RELATIONS
06800 SET:OF:MAYBE:RELATIONS)
06900 DO (TRANSFER element FROM SET:OF:RELATIONS
07000 TO SET:OF:NO:RELATIONS))))
07100 We easily pick RELATION as the dummy argument "element" above.
07200
07300 COMMENT
07400 If the setdifference is not a singleton, then we may err in
07500 choosing which relation to transfer. Some type of insurance may need to
07600 be set up at that point in the FORSOME loop. THe TRANSFER is a permanent
07700 type; we transfer possibly to the current value of SET:OF:NO:RELATIONS,
07800 but definitely to the place where this set is stored permanently: the
07900 property list of CLASS:NAME, under the indicator NO:RELATIONS.
08000 end of COMMENT
08100
08200 end of ENCODE
08300
08400 end of CLARIFY:IMPROBABLE:SECTION
08500
08600 Back in REPEATEDLY loop.
08700
08800 ADAPT:PRECONCEIVED:FUNCTION
08900
09000 CHOOSE
09100
09200 REPEATEDLY
09300
09400 GENERATE
09500 Produces FORSOME
09600 end of GENERATE
09700
09800 COMPARE
09900 end of COMPARE
10000
10100 GENERATE
10200 Produces TRANSFER
10300 end of GENERATE
10400
10500 COMPARE
10600 Since the transfer is inside the forsome loop, we prefer to
10700 work on it first.
10800 end of COMPARE
10900
11000 GENERATE
11100 fails
11200 end of GENERATE
11300
11400 end of REPEATEDLY
11500
11600 end of CHOOSE
11700
11800 So we will work on TRANSFER.
11900
12000 ENCODE
12100 We create a new context, replace TRANSFER by TRANSFER:2,
12200 and recollect what we know. We are doing a permanent type of transfer,
12300 which means altering the permanent copy of the set we are transferring
12400 into -- if such a copy exists. The element to be transferred is a
12500 relation, a list of atoms. The set we are inserting it into is a class,
12600 each of whose elements is a list of atoms. It is stored permanently
12700 on the property list of CLASS:NAME, under the property NO:RELATIONS.
12800 We must also delete the element from the permanent copy of the FROM
12900 list, if one exists. This does not exist; there is no permanent copy of
13000 SET:OF:RELATIONS. Its structure is the same as that of the previous list.
13100 Since we are transferring into a class, we needn't worry about ordering.
13200 We also recall that the two actual arguments -- the temporary, current
13300 names for the FROM and TO sets -- may not in fact be changed. We must
13400 create two new sets which hold the modified lists. Later, we will decide
13500 precisely what is wanted here. If we should have modified the arguments,
13600 well that will be easy to change. If we had done it the other way,
13700 modifying now and having to unmodify later, that is more complicated.
13800 Thus we are ready to choose the proper template of transferring:
13900 (DEFINQ (TRANSFER (LAMBDA (element FROM from:set TO to:set)
14000 (SETQ new:copy:of:to:set (CONS element to:set))
14100 (INSERT element permanent:copy:of:to:set)
14200 (SETQ new:copy:of:from:set (PULL:OUT element from:set))
14300 )))
14400 We substitute in SET:OF:RELATIONS for from:set,
14500 SET:OF:NO:RELATIONS for to:set, RELATION for element,
14600 (PROPERTY NO:RELATIONS ON PROPERTY:LIST OF CLASS:NAME) for
14700 permanent:copy:of:to:set, and
14800 we again get new variable names for the new copies. But we notice that
14900 if we get to this point, then we failed to use the new:copy names from
15000 section one, that is, from TRANSFER:1. So we don't automatically reject
15100 them from plausible names. In fact we choose NEW:SET:OF:RELATIONS,
15200 NEW:SET:OF:NO:RELATIONS; the first of these was in fact chosen before.
15300 WE heavily comment this point, and will quickly change its name if we
15400 find we were wrong. We chose it in the first place to give the outermost
15500 COND the nice property that whichever piece was done, NEW:SET:OF:RELATIONS
15600 would have a value. This is often what is wanted. In any event
15700 this completes the code.
15800
15900 COMMENT
16000 We assert various comments, including the fact that this
16100 function expects that element really will be a member of the from:set.
16200 We also mark the new variables' names, so that we can change them later.
16300 This would be necessary if (a) it turned out we were supposed to actually
16400 modify the temporary copies as well as the permanent ones, or (b) if it
16500 turned out we used these new variables frequently, and the user didn't
16600 like how they were named. Notice that both of these are very minor points,
16700 and therefore we don't try to settle this now.
16800 end of COMMENT
16900
17000 We assert and eval the definition.
17100 end of ENCODE
17200
17300 end of ADAPT:PRECONCEIVED:FUNCTION
17400
17500 Back in outermost REPEATEDLY loop again.
17600
17700 ADAPT:PRECONCEIVED:FUNCTION
17800
17900 CHOOSE
18000
18100 REPEATEDLY
18200
18300 GENERATE
18400 Produces FORSOME
18500 end of GENERATE
18600
18700 COMPARE
18800 end of COMPARE
18900
19000 GENERATE
19100 Produces INSERT
19200 end of GENERATE
19300
19400 COMPARE
19500 Since the transfer is inside the forsome loop,
19600 and the insert is inside the transfer, we choose to work on INSERT first.
19700 work on it first.
19800 end of COMPARE
19900
20000 GENERATE
20100 fails
20200 end of GENERATE
20300
20400 end of REPEATEDLY
20500
20600 end of CHOOSE
20700
20800 So we are going to adapt INSERT. The situation is much simpler
20900 than it was for INSERT:1, since now we have no associated structures
21000 to worry about. We simply must stick RELATION into the property list of
21100 CLASS:NAME, as part of the list stored under property NO:RELATIONS.
21200
21300
21400
21500 ENCODE
21600 We create a new context, and rename INSERT as INSERT:2:1.
21700 We recognize insertion from a property list, and in fact we earlier
21800 worried about just this piece of code. The proper template is easily
21900 found:
22000 (DEFINEQ (INSERT (LAMBDA (element (PROPERTY property:name ON
22100 PROPERTY:LIST OF name))
22200 (PROG (temp)
22300 (SETQ temp (GET name property:name))
22400 (SETQ temp (CONS element temp))
22500 (PUT name property:name temp)
22600 ))))
22700 All the variable names are known and substitutable, except for temp.
22800 This is a dummy temporary variable, so we don't bother the user to
22900 get a name for it.
23000
23100 GET:NAME
23200
23300 PLAUSIBLE:NAMES
23400 {TEMP, TEMPORARY, TEMP:SET:OF:NO:RELATIONS, T, ...}
23500 end of PLAUSIBLE:NAMES
23600
23700 Say we pick TEMPORARY:NO:RELATIONS.
23800 end of GET:NAME
23900
24000 So our code now looks something like this:
24100 (DEFINEQ (INSERT:2:1 (LAMBDA (RELATION (PROPERTY NO:RELATIONS ON
24200 PROPERTY:LIST OF CLASS:NAME))
24300 (PROG (TEMPORARY:NO:RELATIONS)
24400 (SETQ TEMPORARY:NO:RELATIONS (GET CLASS:NAME NO:RELATIONS))
24500 (SETQ TEMPORARY:NO:RELATIONS
24600 (CONS RELATION TEMPORARY:NO:RELATIONS))
24700 (PUT CLASS:NAME NO:RELATIONS TEMPORARY:NO:RELATIONS)
24800 ))))
24900 This completes the coding of the INSERT.
25000
25100 COMMENT
25200 We tack on various comments about what we've done. In
25300 particular, note that we must make ON, PROPERTY, PROPERTY:LIST, OF
25400 all have some value (though their value isn't used, they must
25500 nevertheless be defined as something). This comes under the heading
25600 of global, permanent initialization, and will be taken care of later.
25700 We see this has been noted before. We record the schema used for this
25800 version of INSERT. We find it is the same as the one used for INSERT:1:1.
25900 We look closer, and we see that they are the same function, differing only
26000 in argument names and dummy variable names. We make a note that if this
26100 condition exists at the end of CF, then we can replace both functions by
26200 one of them. In that case, we would generalize the names of the variables
26300 (for example, if a var. has name TEMPORARY:YES:RELATIONS in one, and
26400 TEMPORARY:NO:RELATIONS in another version, then we might replace these by
26500 TEMPORARY:YES:OR:NO:RELATIONS in the combined version).
26600 end of COMMENT
26700
26800 end of ENCODE
26900
27000 end of ADAPT:PRECONCEIVED:FUNCTION
27100
27200 ADAPT:PRECONCEIVED:FUNCTION
27300
27400 CHOOSE
27500
27600 REPEATEDLY
27700
27800 GENERATE
27900 Produces FORSOME
28000 end of GENERATE
28100
28200 COMPARE
28300 end of COMPARE
28400
28500 GENERATE
28600 fails
28700 end of GENERATE
28800
28900 end of REPEATEDLY
29000
29100 end of CHOOSE
29200
29300 So we are going to adapt FORSOME. This is typically a simple function
29400 We have a note cautioning us that, unless the set to choose from is a
29500 singleton, we could err in our choice. Thus it's important to decide how to
29600 resolve such a dilemma before coding FORSOME. This is the task of a demon
29700 we created when we put the COND in just after the call to ASK:FOR:1.
29800
29900 OBEY:DEMON (RESOLVE:DECISION)
30000 We don't know any more about this than when we set the demon up.
30100
30200 MESSAGE
30300 "Pup: If there is more than one relation in the SET:OF:RELATIONS
30400 of ELEMENT that is not also in the SET:OF:MAYBE:RELATIONS of CLASS:NAME,
30500 how do I choose which RELATION to transfer from SET:OF:RELATIONS to
30600 NO:RELATIONS?"
30700 end of MESSAGE
30800
30900 Say user types back "Choose randomly".
31000 This is recognized as meaning the question is irrelevant, we can implement
31100 any strategy we choose.
31200 end of OBEY:DEMON
31300
31400 A note is asserted, mentioning that we may in fact err in our
31500 choice. If we do, we might have to back up in some way and choose again.
31600 This would entail storage of the alternatives along with the chosen
31700 relation, on the NO:RELATIONS list. That is, each element of that list
31800 would have a list of alternatives associated with it. This is something
31900 to keep in mind. We won't ask the user until the choice would make a
32000 difference in how we would proceed.
32100
32200 ENCODE
32300 We create a new context, replace FORSOME by FORSOME:2, and look
32400 up what the easiest method of choosing from a set is: if the set is
32500 stored as a LISP list, it is simplest to take the CAR of the list.
32600 We pick the template
32700 (DEFINEQ (FORSOME (LAMBDA (element IN set DO
32800 (action ←←fixed:args element ←←fixed:args2))
32900 (COND ((NULL set) failure:condition))
33000 (SETQ element (CAR set))
33100 (action ←←fixed:args element ←←fixedargs2)
33200 )))
33300 We see that the arguments' names are unimportant, and if the actual
33400 arguments are too complex, we shall replace them by plausible substitiutes.
33500 Thus we arrive at something like:
33600 (DEFINEQ (FORSOME:2 (LAMBDA (RELATION IN SET:DIFF DO (TRANSFER:2 RELATION
33700 FROM SET:OF:RELATIONS TO SET:OF:NO:RELATIONS))
33800 (COND ((NULL SET:DIFF) failure:condition))
33900 (SETQ RELATION (CAR SET:DIFF))
34000 (TRANSFER:2 RELATION FROM SET:OF:RELATIONS
34100 TO SET:OF:NO:RELATIONS)
34200 )))
34300 The only thing left to fill in is what we return if there is no element
34400 to choose; that is, if the setdifference is NIL. Since this function
34500 is being executed for effects rather than value, this is not too
34600 important. We would like it simply to be different than if we succeed.
34700 We therefore substitute NIL for failure:condition, and we add T at the
34800 end of the function definition, that is, if we succeed.
34900 (DEFINEQ (FORSOME:2 (LAMBDA (RELATION IN SET:DIFF DO (TRANSFER:2 RELATION
35000 FROM SET:OF:RELATIONS TO SET:OF:NO:RELATIONS))
35100 (COND ((NULL SET:DIFF) NIL))
35200 (SETQ RELATION (CAR SET:DIFF))
35300 (TRANSFER:2 RELATION FROM SET:OF:RELATIONS
35400 TO SET:OF:NO:RELATIONS)
35500 T
35600 )))
35700 This completes the encoding of FORSOME.
35800
35900 COMMENT
36000 We reaffirm the fact that backtracking may have to be
36100 implemented, and we add the discussion of the method we could use,
36200 as discussed earlier. We add that FORSOME:2 does not require the
36300 set to be non-null, and that a return of T indicates success, NIL
36400 indicates failure.
36500 We again record the template of this FORSOME, notice it is similar to
36600 FORSOME:1, investigate, and sure enough we find the two functions to
36700 be identical, modulo dummy variable names and argument names. As usual,
36800 we don't combine them yet, but make a note that if they are still the same
36900 when CF is complete, then we can combine them.
37000 end of COMMENT
37100
37200 end of ENCODE
37300
37400 end of ADAPT:PRECONCEIVED:FUNCTION
00100
00200 We are once more back in the REPEATEDLY loop of WRITE:PROGRAM. We check
00300 that CF is not complete, and we go on. There are no undefined
00400 functions in our code, not even any preconceived but unadapted ones.
00500
00600 CLARIFY:IMPROBABLE:SECTION
00700
00800 CHOOSE:FROM
00900 A strange thing happens whenever an infinite loop is present,
01000 so we would like to unburden ourselves about that.
01100 end of CHOOSE:FROM
01200
01300 It is difficult to tell whether the loop, in the form of the infinite
01400 recursion of PARTITION:A:DOMAIN, is actually an error. There is no code
01500 exisiting yet that should be executed after PARTITION:A:DOMAIN. We try to
01600 ask ourselves why we would want to leave it. The only reason we can come
01700 up with is the stock argument against an unbreakable recursion: we might
01800 want to stop the program sometime. This is a fairly sophistocated concept
01900 actually. Now that we know specifically what to ask, we do so:
02000
02100 MESSAGE
02200 "Pup: Should the program be able to halt itself?"
02300 end of MESSAGE
02400
02500 Say the user types Yes. Okay, we must insert some type of
02600 conditional branch inside of PARTITION:A:DOMAIN. A likely spot is just
02700 before it calls itself recursively. This all depends upon the condition
02800 of course, so we waste no more time now guessing.
02900
03000 MESSAGE
03100 "Pup: When we are partitioning the domain, and it is time to
03200 halt, how do we know to halt instead of just continuing on?"
03300 end of MESSAGE
03400
03500 Say the user types "halt if the class name is HALT".
03600 We translate this, to (COND ((EQUAL CLASS:NAME (QUOTE HALT))
03700 (HALT)) (T continue:on:in:PARTITION:A:DOMAIN)). But from programming
03800 knowledge, we know this can easily be done as follows: locate the point
03900 where we first get CLASS:NAME; split the rest of the function off into
04000 a new function f'. Put in the above COND, with the continue:on replaced
04100 by a call to f'. We do this structural modification without too much
04200 trouble: the point referred to is in INPUT:2 subroutine,
04300 just after (SETQ CLASS:NAME ...). This means that the break should
04400 occur just after the COND in PARTITION... But nothing occurs after this
04500 point except the recursion. So we don't have to break the function
04600 after all. We just follow that COND with the new COND:
04700 (COND ((EQUAL CLASS:NAME (QUOTE HALT)) (HALT)) (T (GO START:OF:SERIES)))
04800 where we saw to replace continue:on... by the only thing left to do in
04900 PARTITON:A:DOMAIN. We notice this introduces the new function HALT
05000 as something to be defined.
05100 end of CLARIFY:IMPROBABLE:SECTION
05200
05300 In REPEATEDLY loop again.
05400
05500 FILL:IN:UNDEFINED:SECTION
05600 The choice is from a singleton set. We shall work on HALT.
05700 We know that this involves a few possibilities:
05800
05900 TYPE
06000 (23) Should some data be outputted at this time?
06100 (24) Should we automatically re-enter the system at some point?
06200 Affected: Whether or not we terminate with a call to a system function
06300 (a) ability to continue where we left off
06400 (b) ability to start over again with no trace of previous work
06500 (c) both of the above
06600 (d) neither of the above
06700 end of TYPE
06800
06900 We easily defer (23) until output format worrying time is here
07000 (much later). We must do (24) before we can code HALT. So we ask the
07100 user to choose among the four alternatives. Say he chooses (a). We
07200 know from programming knowledge that we must therefore have
07300 (i) the statement after the call to HALT is a function call; then we just
07400 call that function from here.
07500 (ii) the statement after the call is a GO to the beginning of the same
07600 function. Then we just call that same function.
07700 (iii) the statement is neither of these. Then we probably will split
07800 the function at that point and have a call in HALT to the
07900 second part of the split function.
08000 We are in situation (ii), so there is no worry.
08100
08200 ENCODE
08300 We create a new context, replace HALT by HALT:1, and pick a schema:
08400 (DEFINEQ (←fn (LAMBDA ←arglist ←conditional:function:call)))
08500 which becomes
08600 (DEFINEQ (HALT:1 (LAMBDA NIL
08700 (COND (condition:of:when:we:should:continue:on
08800 call:function:that:the:call:to:HALT:1:appears:in))
08900 )))
09000 The latter unknown is simply recognized as (PARTITION:A:DOMAIN). The
09100 former is unknown and we must ask about it:
09200
09300 MESSAGE
09400 "Pup: If we are about to HALT, when should we decide to
09500 continue on instead?"
09600 end of MESSAGE
09700
09800 Say user types "Ask me if you should continue on".
09900 This is translated, and we infer that the user meant "if I answer
10000 yes then continue on, otherwise do not continue on." This is turned
10100 into (COND ((EQUAL (ASK:FOR (QUOTE SHOULD:I:CONTINUE:ON))
10200 (QUOTE YES))
10300 (PARTITION:A:DOMAIN))
10400 (T NIL)).
10500 This is all of HALT:1 we need to do now, so we stop.
10600 end of ENCODE
10700
10800 end of FILL:IN:UNDEFINED:SECTION
10900
11000 Back in REREATEDLY.
11100
11200 ADAPT:PRECONCEIVED:FUNCTION
11300 There is only one to choose from: ASK:FOR.
11400
11500 ENCODE
11600 We create a new context, suffix :2 onto ASK:FOR, and begin:
11700 (DEFINEQ (ASK:FOR (LAMBDA (SHOULD:I:CONTINUE:ON)
11800 (PRIN1 (QUOTE "PLEASE GIVE ME"))
11900 (PRINT SHOULD:I:CONTINUE:ON)
12000 (SETQ SHOULD:I:CONTINUE:ON (READ))
12100 )))
12200 end of ENCODE
12300
12400 end of ADAPT:PRECONCEIVED:FUNCTION
12500
12600 Back in outermost loop again. We see CF is not completed yet.
12700
12800 CLARIFY:IMPROBABLE:SITUATION
12900
13000 CHOOSE:FROM
13100 We have as one of our choices, the fact that if a class name is
13200 read in with ELEMENT, and that class name is already on the list, then
13300 nothing whatsoever is done. This seems mildly strange. But a similar
13400 situation prevails after reading CORRECT:CLASS:NAME. So we essentially
13500 have twice as good a reason for investigating this as anything else.
13600 end of CHOOSE:FROM
13700
13800 We see whether or not this is incorrect.
13900 What use could we put the class name to in such a case? We give up and ask
14000
14100 MESSAGE
14200 "Pup: If I read in an element which has a class name already on
14300 the list of possible class names, what should I do?"
14400 end of MESSAGE
14500
14600 Say the user types "Reconcile the existing description of the class
14700 to encompass the element". Pup recognizes (reconcile x to encompass y)
14800 as meaning: alter the parts of x as necessary, so that y will be associated
14900 with x. In our case, this means alter the property list lists of
15000 CLASS:NAME in such a way that there is no contradiction with ELEMENT.
15100 Well, how could element contradict the class lists? All the relations in
15200 SET:OF:RELATIONS are of the 0<p≤1 type. Thus, we could get an outright
15300 contradiction only if some relation were on the YES:RELATIONS list but not
15400 in SET:OF:RELATIONS or if some relation were on the NO:RELATIONS list
15500 but were in SET:OF:RELATIONS. Finally, we can add all the relations in
15600 SET:OF:RELATIONS that aren't already on some list to the MAYBE:RELATIONS
15700 list. What should we do in each case? If we find a YES:RELATION absent,
15800 we know we erred in choosing it. If a back-up system exists, this is
15900 where we back up and choose a different relation to transfer from
16000 MAYBE:RELATIONS to YES:RELATIONS. In any event we'll have to transfer
16100 the incorrect one back from YES:RELATIONS to MAYBE:RELATIONS. A similar
16200 train of reasoning holds if there is a NO:RELATION present in the
16300 SET:OF:RELATIONS.
16400
16500 ENCODE
16600 Just at the end of INPUT:2 we will insert the code we write.
16700 We create a new context and put there
16800 (COND ((MEMBER CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES)
16900 (RECONCILE CLASS:NAME ELEMENT))
17000 )
17100 We now must define RECONCILE. We create a new context, replace it by
17200 RECONCILE:1, and choose a template.
17300 As the discussion above indicates, reconciliation is close to comparison.
17400 If the two objects have structure, we must reconcile corresponding
17500 parts. Thus we choose
17600 (DEFINEQ (RECONCILE (LAMBDA (x y)
17700 (RECONCILE part:1:of:x corresponding:part:of:y)
17800 (RECONCILE part:2:of:x corresponding:part:of:y)
17900 .
18000 .
18100 .
18200 (RECONCILE part:N:of:x corresponding:part:of:y)
18300 )))
18400 This quickly is instantiated as
18500 (DEFINEQ (RECONCILE:1 (LAMBDA (CLASS:NAME ELEMENT)
18600 (RECONCILE:1:1 list:of:objects:of:class LIST:OF:OBJECTS:OF:ELEMENT)
18700 (RECONCILE:1:2 set:of:yes:relations SET:OF:RELATIONS)
18800 (RECONCILE:1:3 set:of:no:relations SET:OF:RELATIONS)
18900 (RECONCILE:1:4 set:of:maybe:relations SET:OF:RELATIONS)
19000 )))
19100 We recall what each of the unnamed variables is, and how to get it.
19200 We call them by themselves (small letters into capitals) and
19300 preface these four calls by the four initializations:
19400 (SETQ LIST:OF:OBJECTS:OF:CLASS (GET CLASS:NAME CLASS:OBJECTS))
19500 (SETQ SET:OF:YES:RELATIONS (GET CLASS:NAME YES:RELATIONS))
19600 (SETQ SET:OF:NO:RELATIONS (GET CLASS:NAME NO:RELATIONS))
19700 (SETQ SET:OF:MAYBE:RELATIONS (GET CLASS:NAME MAYBE:RELATIONS))
19800 This completes the code for RECONCILE:1
19900
20000 COMMENT
20100 end of COMMENT
20200
20300 end of ENCODE
20400
20500 end of CLARIFY:IMPROBABLE:SECTION
20600
20700 Back in the outermost REPEATEDLY loop. We have some new preconceived
20800 functions to adapt now.
20900
21000 ADAPT:PRECONCEIVED:FUNCTION
21100 The only function to choose is RECONCILE. The first call is
21200 deferred, since we draw an analogy to COMPARE:1:1 and see that
21300 RECONCILE:1:1 might be trivial. The other three are basically equal,
21400 so suppose we pick RECONCILE:1:2 to work on first.
21500
21600 ENCODE
21700 We create a new context. To reconcile the set of yes relations
21800 to the set of relations of element, we must transfer all relations
21900 from yes relations to maybe relations if they are in yes relations but
22000 not in set of relations. Thus we can write the code:
22100 (DEFINEQ (RECONCILE:1:2 (LAMBDA (SET:OF:YES:RELATIONS SET:OF:RELATIONS)
22200 (FOREACH RELATION IN (SETDIFFERENCE SET:OF:YES:RELATIONS
22300 SET:OF:RELATIONS)
22400 DO (TRANSFER RELATION FROM SET:OF:YES:RELATIONS
22500 TO SET:OF:MAYBE:RELATIONS)
22600 )
22700 )))
22800
22900 COMMENT
23000 We note that the transfer is of the previous, permanent-copy
23100 type. The foreach is definitely the "exhaust the set" type, not "until
23200 some condition is true" type. This is the stock FOREACH function, and
23300 cannot be altered. It it therefore a supplied primitive, not a preconceived
23400 function which has still to be adapted. We shan't consider it further.
23500 We pass along the notes about inserting
23600 backup features. In particular, they would appear here as part of the
23700 DO operations.
23800 end of COMMENT
23900
24000 end of ENCODE
24100
24200 end of ADAPT:PRECONCEIVED:FUNCTION
24300
24400 Back in the outermost REPEATEDLY loop. We have some new preconceived
24500 functions to adapt now.
24600
24700 ADAPT:PRECONCEIVED:FUNCTION
24800 The only function to choose is RECONCILE. The first call is
24900 deferred, since we draw an analogy to COMPARE:1:1 and see that
25000 RECONCILE:1:1 might be trivial. The other two are basically equal,
25100 so suppose we pick RECONCILE:1:3 to work on first.
25200
25300 ENCODE
25400 We create a new context. To reconcile the set of no:relations
25500 to the set of relations of element, we must transfer all relations
25600 from set of relations to maybe relations if they are in set of relations
25700 and also in set of no:relations. Thus we can write the code:
25800 (DEFINEQ (RECONCILE:1:3 (LAMBDA (SET:OF:NO:RELATIONS SET:OF:RELATIONS)
25900 (FOREACH RELATION IN (SETINTERSECTION SET:OF:RELATIONS
26000 SET:OF:NO:RELATIONS)
26100 DO (TRANSFER RELATION FROM SET:OF:NO:RELATIONS
26200 TO SET:OF:MAYBE:RELATIONS)
26300 )
26400 )))
26500
26600 COMMENT
26700 We note that the transfer is of the previous, permanent-copy
26800 type. The foreach is definitely the "exhaust the set" type, not "until
26900 some condition is true" type. We pass along the notes about inserting
27000 backup features. In particular, they would appear here as part of the
27100 DO operations.
27200 end of COMMENT
27300
27400 end of ENCODE
27500
27600 end of ADAPT:PRECONCEIVED:FUNCTION
27700
27800 Back in the outermost REPEATEDLY loop. We have some new preconceived
27900 functions to adapt now.
28000
28100 ADAPT:PRECONCEIVED:FUNCTION
28200 The only function to choose is RECONCILE. The first call is
28300 deferred, since we draw an analogy to COMPARE:1:1 and see that
28400 RECONCILE:1:1 might be trivial.
28500 So we pick RECONCILE:1:4 to work on now.
28600
28700 ENCODE
28800 We create a new context. To reconcile the set of relations
28900 to the set of maybe relations, we must transfer all relations from
29000 set of relations to maybe relations if they are in set of relations but
29100 not already in set of maybe or yes relations. Thus we can write the code:
29200 (DEFINEQ (RECONCILE:1:4 (LAMBDA (SET:OF:MAYBE:RELATIONS SET:OF:RELATIONS)
29300 (FOREACH RELATION IN (SETDIFFERENCE SET:OF:RELATIONS
29400 (SETUNION SET:OF:MAYBE:RELATIONS
29500 SET:OF:YES:RELATIONS))
29600 DO (TRANSFER RELATION FROM SET:OF:RELATIONS
29700 TO SET:OF:MAYBE:RELATIONS)
29800 )
29900 )))
30000
30100 COMMENT
30200 We note that the transfer is of the previous, permanent-copy
30300 type. The foreach is definitely the "exhaust the set" type, not "until
30400 some condition is true" type. We pass along the notes about inserting
30500 backup features. In particular, they would probably not appear here.
30600 end of COMMENT
30700
30800 end of ENCODE
30900
31000 end of ADAPT:PRECONCEIVED:FUNCTION
31100
31200 Back in the outermost REPEATEDLY loop. We have one more preconceived
31300 function to adapt now.
31400
31500 ADAPT:PRECONCEIVED:FUNCTION
31600 The only function to choose is RECONCILE. The first call is
31700 no longer deferred, since it is the only one remaining. We admit that
31800 RECONCILE:1:1 might be trivial.
31900 Before encoding this, we must get some grasp of what is required.
32000 As of now, we see nothing that has to be done. Before asking the user,
32100 we try to think of some possibilities. Why reconcile two lists before
32200 reconciling relations on their elements? Well, the two lists might have
32300 the same elements, but in a different order, and all we might have to do
32400 is reorder one of the lists. But this wouldn't affect any of the subse-
32500 quent RECONCILE functions, so we tag this as unlikely. What else could
32600 be different between the two lists of objects? Well, they might have
32700 differently named elements, and the reconciliation would be a sort of
32800 re-writing (too crude to be called translation) of all the relations
32900 of the element into those corresponding to objects of the class, or vice
33000 versa. Why else? The lists could differ in structure. How? Complexity
33100 of elements, perhaps. No, this is ruled out: both are lists of atoms.
33200 Length, perhaps. Well, what would it mean if they differred in length?
33300 Again, some type of rewriting would be necessary. Both of these operations
33400 could be best gotten from examples. We are now ready to ask the user:
33500
33600 MESSAGE
33700 "Pup: Before reconciling the relations of ELEMENT with the
33800 relations of the existing class, I reconcile the lists of objects. I
33900 do not know what this involves, so please tell me. I can think of
34000 some possibilities: if the lists differ in length or names of elements,
34100 that might require re-writing the relations, deleting some, etc.
34200 If nothing is to be done, type NOTHING. If my guess is correct type
34300 OK. Otherwise, please type what I must do to the two lists of objects."
34400 end of MESSAGE
34500
34600 Say the user types OK.
34700 Pup knows that the best way to understand what must be done is through
34800 examples. This is because the renaming function is a purely structural
34900 rearrangement type of list processing function. Pup now must decide
35000 whether to make up part of the examples, make up the directions for
35100 the examples, or simply ask for examples. We try to do as much as
35200 possible. We feel hesitant to make u the examples ourselves, since
35300 we don't really know the range of complexity of the function.
35400 But we do know the parts of the example: in particular, there will be
35500 supplied two lists of atoms, and each may be reordered and renamed
35600 and added to or deleted from, so there will be two modified lists of
35700 atoms as results. Pup recognizes that one of these may be simply
35800 the same as it was on input; in that case we would be using it to
35900 modify the other input list. If both lists are diffeent, we are using
36000 each to modify the other. Finally, Pup will decide how many examples to
36100 ask for, and will specify that it wants an easy, average, or very hard
36200 example each time. I am not sure yet where all this knowledge about
36300 learning from examples should go, and where we access it from. The
36400 actual learning-synthesis program will be a modification of the one(s)
36500 the group has done in the past, and will be glossed over here.
36600 The ensuing Pup/user dialog might go like:
36700
36800 (capitals represent USER, small letters represent things typed by Pup)
36900
37000 pup: give me a medium-hard example, please
37100
37200 input 1: the list of objects of element: (A B C D)
37300 input 2: the list of objects of the class: (E F G H I)
37400 output 1: the modified element objects: (E F G H)
37500 output 2: the modified class objects: (E F G H I)
37600
37700 pup: give me a medium-hard example, please
37800
37900 input 1: the list of objects of element: (A B C D E F)
38000 input 2: the list of objects of the class: (G H I J)
38100 output 1: the modified element objects: (G H I J E F)
38200 output 2: the modified class objects: (G H I J E F)
38300
38400 pup: give me a medium-hard example, please
38500
38600 input 1: the list of objects of element: (A B C D)
38700 input 2: the list of objects of the class: (E F G H)
38800 output 1: the modified element objects: (E F G H)
38900 output 2: the modified class objects: (E F G H)
39000
39100 pup: give me a medium-hard example, please
39200
39300 input 1: the list of objects of element: (A B)
39400 input 2: the list of objects of the class: (C D E F G)
39500 output 1: the modified element objects: (C D)
39600 output 2: the modified class objects: (C D E F G)
39700
39800 pup: give me a medium:hard example, please
39900
40000 input 1: the list of objects of element: (A B C D E F G)
40100 input 2: the list of objects of the class: (H I)
40200 output 1: the modified element objects: (H I C D E F G)
40300 output 2: the modified class objects: (H I C D E F G)
40400
40500 pup: give me a medium-hard example, please
40600
40700 input 1: the list of objects of element: (A B C D E F)
40800 input 2: the list of objects of the class: (F D C A B G E)
40900 output 1: the modified element objects: (F D C A B G)
41000 output 2: the modified class objects: (F D C A B G E)
41100
41200 pup: give me a medium-hard example, please
41300
41400 input 1: the list of objects of element: (A B C D E F G)
41500 input 2: the list of objects of the class: (F D C A B E)
41600 output 1: the modified element objects: (F D C A B E G)
41700 output 2: the modified class objects: (F D C A B E G)
41800
41900 pup: give me a medium-easy example, please
42000
42100 input 1: the list of objects of element: (A B C D)
42200 input 2: the list of objects of the class: (E)
42300 output 1: the modified element objects: (E B C D)
42400 output 2: the modified class objects: (E B C D)
42500
42600 pup: give me a medium-easy example, please
42700
42800 input 1: the list of objects of element: (A B C D E F G)
42900 input 2: the list of objects of the class: ()
43000 output 1: the modified element objects: (A B C D E F G)
43100 output 2: the modified class objects: (A B C D E F G)
43200
43300 pup: give me a medium-easy example, please
43400
43500 input 1: the list of objects of element: ()
43600 input 2: the list of objects of the class: (F D C A B G E)
43700 output 1: the modified element objects: ()
43800 output 2: the modified class objects: (F D C A B G E)
43900
44000 pup: give me a medium-easy example, please
44100
44200 input 1: the list of objects of element: (A)
44300 input 2: the list of objects of the class: (F)
44400 output 1: the modified element objects: (F)
44500 output 2: the modified class objects: (F)
44600
44700 pup: give me a medium-easy example, please
44800
44900 input 1: the list of objects of element: (A B)
45000 input 2: the list of objects of the class: (B A)
45100 output 1: the modified element objects: (B A)
45200 output 2: the modified class objects: (B A)
45300
45400 At this point, Pup should have gotten the definition of the function.
45500 It will look perhaps like the following:
45600
45700 (DEFINEQ (RECONCILE:1:1 (LAMBDA (LIST:OF:OBJECTS:OF:CLASS
45800 LIST:OF:OBJECTS:OF:ELEMENT)
45900 (SETQ NEW:LIST:OF:OBJECTS:OF:CLASS (RENAME:1:1 LIST:OF:OBJECTS:OF:CLASS
46000 LIST:OF:OBJECTS:OF:ELEMENT))
46100 (SETQ NEW:LIST:OF:OBJECTS:OF:ELEMENT
46200 (RENAME:1:2 LIST:OF:OBJECTS:OF:CLASS LIST:OF:OBJECTS:OF:ELEMENT))
46300 (re-write SET:OF:RELATIONS using LIST:OF:OBJECTS:OF:ELEMENT
46400 NEW:LIST:OF:OBJECTS:OF:ELEMENT)
46500 (re:write SET:OF:YES:RELATIONS using LIST:OF:OBJECTS:OF:CLASS
46600 NEW:LIST:OF:OBJECTS:OF:CLASS)
46700 (re:write SET:OF:NO:RELATIONS using LIST:OF:OBJECTS:OF:CLASS
46800 NEW:LIST:OF:OBJECTS:OF:CLASS)
46900 (re:write SET:OF:MAYBE:RELATIONS using LIST:OF:OBJECTS:OF:CLASS
47000 NEW:LIST:OF:OBJECTS:OF:CLASS)
47100 (re:write LIST:OF:OBJECTS:OF:ELEMENT using NEW:LIST:OF:OBJECTS:OF:ELEMENT)
47200 (re:write LIST:OF:OBJECTS:OF:CLASS using NEW:LIST:OF:OBJECTS:OF:CLASS)
47300 )))
47400
47500 (DEFINEQ (RENAME:1:1 (LAMBDA (L1 L2)
47600 (APPEND
47700 (COND
47800 (L1
47900 (COND
48000 (L2 (LIST (CAR L2)))
48100 (T (LIST (CAR L1)))
48200 )
48300 (T
48400 (COND
48500 (L2 (LIST (CAR L2)))
48600 (T NIL)
48700 )
48800 )
48900 )
49000 (COND
49100 ((OR L1 L2)
49200 (RENAME:1:1 (CDR L1) (CDR L2))
49300 )
49400 (T NIL)
49500 )
49600 )
49700 )))
49800
49900 (DEFINEQ (RENAME:1:2 (LAMBDA (L1 L2)
50000 (APPEND
50100 (COND
50200 ((AND L1 L2) (LIST (CAR L2)))
50300 (T L1)
50400 )
50500 (COND
50600 ((AND L1 L2) (RENAME:1:2 (CDR L1) (CDR L2)))
50700 (T NIL)
50800 )
50900 )
51000 )))
51100
51200 COMMENT
51300 We know that the re:write functions affecting the sets of
51400 yes, no, and maybe relations, are of the permanent-copy altering
51500 type. The same holds for the re:write of SET:OF:RELATIONS, although
51600 of course no permanent copy exists. We again have no question in the
51700 case of the element's list of objects, but we must worry alittle when
51800 we do the re:write of the object list of the class. Here we have a
51900 permanent copy as well as the current one, and it is not trivial
52000 whether or not we should overwrite it. After a slight amount of
52100 consideration, we decide it is necessary to ensure this particular
52200 example being classified correctly next time.
52300 end of COMMENT
52400
52500 end of ADAPT:PRECONCEIVED:FUNCTION
52600
52700 Back in outer REPEATEDLY loop of WRITE:PROGRAM. CF isn't complete.
52800 We look at our alternatives, and see we must adapt the re:write functions.
52900
53000 ADAPT:PRECONCEIVED:FUNCTION
53100 The only choice is from re:write functions. As was discussed earlier,
53200 we will do them in order, since (a) the later ones depend upon the earlier
53300 ones, and (b) in general, we like to do functions earllier in a series
53400 before those later in a series. So we are doing the first rewrite now.
53500
53600 ENCODE
53700 We create a new context, replace re:write by RE:WRITE:1, and
53800 pick our schema. The analogy between reconcile and compare persists;
53900 similar to this rewriting was the transferrring previously.
54000 We choose the schema, allowing the analogy to help us a little:
54100 (DEFINQ (RE:WRITE (LAMBDA (set1 USING set2 set3)
54200 (PROG (old new)
54300 label
54400 (COND ((NULL set2) (RETURN set1))
54500 ((NULL set3) (RETURN set1)))
54600 (SETQ old (CAR set2))
54700 (SETQ new (CAR set3))
54800 (SUBSTITUTE new FOR old IN set1)
54900 (GO label)
55000 )
55100 )))
55200 We know what most of the undefined variables must instantiate to,
55300 and the rest are dummies and easily plausibly-picked. We get:
55400 (DEFINQ (RE:WRITE (LAMBDA (SET:OF:RELATIONS USING
55500 LIST:OF:OBJECTS:OF:ELEMENT NEW:LIST:OF:OBJECTS:OF:ELEMENT)
55600 (PROG (OLD:1 NEW:1)
55700 LABEL:1
55800 (COND ((NULL LIST:OF:OBJECTS:OF:ELEMENT) (RETURN SET:OF:RELATIONS))
55900 ((NULL NEW:LIST:OF:OBJECTS:OF:ELEMENT) (RETURN SET:OF:RELATIONS)))
56000 (SETQ OLD:1 (CAR LIST:OF:OBJECTS:OF:ELEMENT))
56100 (SETQ NEW:1 (CAR NEW:LIST:OF:OBJECTS:OF:ELEMENT))
56200 (SUBSTITUTE NEW:1 FOR OLD:1 IN SET:OF:RELATIONS)
56300 (GO LABEL:1)
56400 )
56500 )))
56600 This completes the code for RE:WRITE:1. Notice that we must still adapt
56700 SUBSTITUTE to this particular call.
56800
56900 COMMENT
57000 The substitute is the simple "find all occurrences and replace
57100 them by the new item" type, no special permanent copies or other messy
57200 details to worry about. We note that the way the function is defined,
57300 the two USING sets may be of different lenghts, yet the way the
57400 RENAME functions are written, they will always be the same length.
57500 If the RENAMEing isn't changed, we can eli minate one half of the
57600 termination check. In fact, this function is really just a cumbersome
57700 form of MAP2CAR, as it now stands. We may later replace it entirely
57800 by a call to this latter function.
57900 end of COMMENT
58000
58100 end of ENCODE
58200
58300 end of ADAPT:PRECONCEIVED:FUNCTION
00100 Back in REPEATEDLY loop.
00200
00300 ADAPT:PRECONCEIVED:FUNCTION
00400 We again have a slew of re:write functions, plus one substitute
00500 function. Again, the choice both seems and is arbitrary. Say we pick
00600 the substitute function to work on.
00700
00800 ENCODE
00900 We create a new context, replace SUBSTITUTE by SUBSTITUTE:1,
01000 and look at the preconception of the function. It is almost a primitive
01100 function, and sure enough no special modifications are necessary now.
01200 (DEFINEQ (SUBSTITUTE:1 (LAMBDA (NEW:1 FOR OLD:1 IN SET:OF:RELATIONS)
01300 (COND ((NULL SET:OF:RELATIONS) NIL)
01400 ((LISTP SET:OF:RELATIONS)
01500 (CONS (SUBSTITUTE:1 NEW:1 FOR OLD:1 IN (CAR SET:OF:RELATIONS))
01600 (SUBSTITUTE:1 NEW:1 FOR OLD:1 IN (CDR SET:OF:RELATIONS))))
01700 ((EQUAL SET:OF:RELATIONS OLD:1) NEW:1)
01800 (T SET:OF:RELATIONS))
01900 )))
02000
02100 COMMENT
02200 We must have IN and FOR initialized.
02300 end of COMMENT
02400
02500 end of ENCODE
02600
02700 end of ADAPT:PRECONCEIVED:FUNCTION
02800
02900 Back in outer REPEATEDLY loop of WRITE:PROGRAM. CF isn't complete.
03000 We look at our alternatives, and see we must adapt the re:write functions.
03100
03200 ADAPT:PRECONCEIVED:FUNCTION
03300 The only choice is from re:write functions. As was discussed earlier,
03400 we will do them in order, since (a) the later ones depend upon the earlier
03500 ones, and (b) in general, we like to do functions earllier in a series
03600 before those later in a series. So we are doing the first rewrite now.
03700
03800 ENCODE
03900 We create a new context, replace re:write by RE:WRITE:2, and
04000 pick our schema. The analogy between reconcile and compare persists;
04100 similar to this rewriting was the transferrring previously.
04200 We choose the schema, allowing the analogy to help us a little:
04300 (DEFINQ (RE:WRITE (LAMBDA (set2 USING set2 set3)
04400 (PROG (old new)
04500 label
04600 (COND ((NULL set2)(store set1 permanent:copy:of:set1) (RETURN set1))
04700 ((NULL set3) (store set1 permanent:copy:of:set1) (RETURN set1)))
04800 (SETQ old (CAR set2))
04900 (SETQ new (CAR set3))
05000 (SUBSTITUTE new FOR old IN set1)
05100 (GO label)
05200 )
05300 )))
05400 We know what most of the undefined variables must instantiate to,
05500 and the rest are dummies and easily plausibly-picked. We get the storing
05600 of the permanent copy as a piece of code we wrote earlier. Finally we have:
05700 (DEFINQ (RE:WRITE (LAMBDA (SET:OF:YES:RELATIONS USING
05800 LIST:OF:OBJECTS:OF:CLASS NEW:LIST:OF:OBJECTS:OF:CLASS)
05900 (PROG (OLD:2 NEW:2)
06000 LABEL:2
06100 (COND ((NULL LIST:OF:OBJECTS:OF:CLASS)
06200 (PUT CLASS:NAME YES:RELATIONS SET:OF:YES:RELATIONS)
06300 (RETURN SET:OF:YES:RELATIONS))
06400 ((NULL NEW:LIST:OF:OBJECTS:OF:CLASS)
06500 (PUT CLASS:NAME YES:RELATIONS SET:OF:YES:RELATIONS)
06600 (RETURN SET:OF:YES:RELATIONS)))
06700 (SETQ OLD:2 (CAR LIST:OF:OBJECTS:OF:CLASS))
06800 (SETQ NEW:2 (CAR NEW:LIST:OF:OBJECTS:OF:CLASS))
06900 (SUBSTITUTE NEW:2 FOR OLD:2 IN SET:OF:YES:RELATIONS)
07000 (GO LABEL:2)
07100 )
07200 )))
07300 This completes the code for RE:WRITE:2. Notice that we must still adapt
07400 SUBSTITUTE to this particular call.
07500
07600 COMMENT
07700 The substitute is the simple "find all occurrences and replace
07800 them by the new item" type, no special permanent copies or other messy
07900 details to worry about. We note that the way the function is defined,
08000 the two USING sets may be of different lenghts, yet the way the
08100 RENAME functions are written, they will always be the same length.
08200 If the RENAMEing isn't changed, we can eliminate one half of the
08300 termination check. In fact, this function is really just a cumbersome
08400 form of MAP2CAR, as it now stands. We may later replace it entirely
08500 by a call to this latter function.
08600 end of COMMENT
08700
08800 end of ENCODE
08900
09000 end of ADAPT:PRECONCEIVED:FUNCTION
09100
09200 Back in REPEATEDLY loop.
09300
09400 ADAPT:PRECONCEIVED:FUNCTION
09500 We again have a slew of re:write functions, plus one substitute
09600 function. Again, the choice both seems and is arbitrary. Say we pick
09700 the substitute function to work on.
09800
09900 ENCODE
10000 We create a new context, replace SUBSTITUTE by SUBSTITUTE:2,
10100 and look at the preconception of the function. It is almost a primitive
10200 function, and sure enough no special modifications are necessary now.
10300 (DEFINEQ (SUBSTITUTE:2 (LAMBDA (NEW:2 FOR OLD:2 IN SET:OF:YES:RELATIONS)
10400 (COND ((NULL SET:OF:YES:RELATIONS) NIL)
10500 ((LISTP SET:OF:YES:RELATIONS)
10600 (CONS (SUBSTITUTE:2 NEW:2 FOR OLD:2 IN (CAR SET:OF:YES:RELATIONS))
10700 (SUBSTITUTE:2 NEW:2 FOR OLD:2 IN (CDR SET:OF:YES:RELATIONS))))
10800 ((EQUAL SET:OF:YES:RELATIONS OLD:2) NEW:2)
10900 (T SET:OF:YES:RELATIONS))
11000 )))
11100
11200 COMMENT
11300 We must have IN and FOR initialized.
11400 We note that this is the same as the last substitute fn., and if it
11500 remains so, we can later combine them into one function.
11600 end of COMMENT
11700
11800 end of ENCODE
11900
12000 end of ADAPT:PRECONCEIVED:FUNCTION
12100
12200 Back in outer REPEATEDLY loop of WRITE:PROGRAM. CF isn't complete.
12300 We look at our alternatives, and see we must adapt the re:write functions.
12400
12500 ADAPT:PRECONCEIVED:FUNCTION
12600 The only choice is from re:write functions. As was discussed earlier,
12700 we will do them in order, since (a) the later ones depend upon the earlier
12800 ones, and (b) in general, we like to do functions earllier in a series
12900 before those later in a series. So we are doing the first rewrite now.
13000
13100 ENCODE
13200 We create a new context, replace re:write by RE:WRITE:3, and
13300 pick our schema. The analogy between reconcile and compare persists;
13400 similar to this rewriting was the transferrring previously.
13500 We choose the schema, allowing the analogy to help us a little:
13600 (DEFINQ (RE:WRITE (LAMBDA (set2 USING set2 set3)
13700 (PROG (old new)
13800 label
13900 (COND ((NULL set2)(store set1 permanent:copy:of:set1) (RETURN set1))
14000 ((NULL set3) (store set1 permanent:copy:of:set1) (RETURN set1)))
14100 (SETQ old (CAR set2))
14200 (SETQ new (CAR set3))
14300 (SUBSTITUTE new FOR old IN set1)
14400 (GO label)
14500 )
14600 )))
14700 We know what most of the undefined variables must instantiate to,
14800 and the rest are dummies and easily plausibly-picked. We get the storing
14900 of the permanent copy as a piece of code we wrote earlier. Finally we have:
15000 (DEFINQ (RE:WRITE (LAMBDA (SET:OF:NO:RELATIONS USING
15100 LIST:OF:OBJECTS:OF:CLASS NEW:LIST:OF:OBJECTS:OF:CLASS)
15200 (PROG (OLD:3 NEW:3)
15300 LABEL:3
15400 (COND ((NULL LIST:OF:OBJECTS:OF:CLASS)
15500 (PUT CLASS:NAME NO:RELATIONS SET:OF:NO:RELATIONS)
15600 (RETURN SET:OF:NO:RELATIONS))
15700 ((NULL NEW:LIST:OF:OBJECTS:OF:CLASS)
15800 (PUT CLASS:NAME NO:RELATIONS SET:OF:NO:RELATIONS)
15900 (RETURN SET:OF:NO:RELATIONS)))
16000 (SETQ OLD:3 (CAR LIST:OF:OBJECTS:OF:CLASS))
16100 (SETQ NEW:3 (CAR NEW:LIST:OF:OBJECTS:OF:CLASS))
16200 (SUBSTITUTE NEW:3 FOR OLD:3 IN SET:OF:NO:RELATIONS)
16300 (GO LABEL:3)
16400 )
16500 )))
16600 This completes the code for RE:WRITE:3. Notice that we must still adapt
16700 SUBSTITUTE to this particular call.
16800
16900 COMMENT
17000 The substitute is the simple "find all occurrences and replace
17100 them by the new item" type, no special permanent copies or other messy
17200 details to worry about. We note that the way the function is defined,
17300 the two USING sets may be of different lenghts, yet the way the
17400 RENAME functions are written, they will always be the same length.
17500 If the RENAMEing isn't changed, we can eliminate one half of the
17600 termination check. In fact, this function is really just a cumbersome
17700 form of MAP2CAR, as it now stands. We may later replace it entirely
17800 by a call to this latter function.
17900 end of COMMENT
18000
18100 end of ENCODE
18200
18300 end of ADAPT:PRECONCEIVED:FUNCTION
18400
18500 Back in REPEATEDLY loop.
18600
18700 ADAPT:PRECONCEIVED:FUNCTION
18800 We again have a slew of re:write functions, plus one substitute
18900 function. Again, the choice both seems and is arbitrary. Say we pick
19000 the substitute function to work on.
19100
19200 ENCODE
19300 We create a new context, replace SUBSTITUTE by SUBSTITUTE:3,
19400 and look at the preconception of the function. It is almost a primitive
19500 function, and sure enough no special modifications are necessary now.
19600 (DEFINEQ (SUBSTITUTE:3 (LAMBDA (NEW:3 FOR OLD:3 IN SET:OF:NO:RELATIONS)
19700 (COND ((NULL SET:OF:NO:RELATIONS) NIL)
19800 ((LISTP SET:OF:NO:RELATIONS)
19900 (CONS (SUBSTITUTE:3 NEW:3 FOR OLD:3 IN (CAR SET:OF:NO:RELATIONS))
20000 (SUBSTITUTE:3 NEW:3 FOR OLD:3 IN (CDR SET:OF:NO:RELATIONS))))
20100 ((EQUAL SET:OF:NO:RELATIONS OLD:3) NEW:3)
20200 (T SET:OF:NO:RELATIONS))
20300 )))
20400
20500 COMMENT
20600 We must have IN and FOR initialized.
20700 We note that this is the same as the last substitute fn., and if it
20800 remains so, we can later combine them into one function.
20900 end of COMMENT
21000
21100 end of ENCODE
21200
21300 end of ADAPT:PRECONCEIVED:FUNCTION
21400
21500 Back in outer REPEATEDLY loop of WRITE:PROGRAM. CF isn't complete.
21600 We look at our alternatives, and see we must adapt the re:write functions.
21700
21800 ADAPT:PRECONCEIVED:FUNCTION
21900 The only choice is from re:write functions. As was discussed earlier,
22000 we will do them in order, since (a) the later ones depend upon the earlier
22100 ones, and (b) in general, we like to do functions earllier in a series
22200 before those later in a series. So we are doing the first rewrite now.
22300
22400 ENCODE
22500 We create a new context, replace re:write by RE:WRITE:4, and
22600 pick our schema. The analogy between reconcile and compare persists;
22700 similar to this rewriting was the transferrring previously.
22800 We choose the schema, allowing the analogy to help us a little:
22900 (DEFINQ (RE:WRITE (LAMBDA (set2 USING set2 set3)
23000 (PROG (old new)
23100 label
23200 (COND ((NULL set2)(store set1 permanent:copy:of:set1) (RETURN set1))
23300 ((NULL set3) (store set1 permanent:copy:of:set1) (RETURN set1)))
23400 (SETQ old (CAR set2))
23500 (SETQ new (CAR set3))
23600 (SUBSTITUTE new FOR old IN set1)
23700 (GO label)
23800 )
23900 )))
24000 We know what most of the undefined variables must instantiate to,
24100 and the rest are dummies and easily plausibly-picked. We get the storing
24200 of the permanent copy as a piece of code we wrote earlier. Finally we have:
24300 (DEFINQ (RE:WRITE (LAMBDA (SET:OF:MAYBE:RELATIONS USING
24400 LIST:OF:OBJECTS:OF:CLASS NEW:LIST:OF:OBJECTS:OF:CLASS)
24500 (PROG (OLD:4 NEW:4)
24600 LABEL:4
24700 (COND ((NULL LIST:OF:OBJECTS:OF:CLASS)
24800 (PUT CLASS:NAME MAYBE:RELATIONS SET:OF:MAYBE:RELATIONS)
24900 (RETURN SET:OF:MAYBE:RELATIONS))
25000 ((NULL NEW:LIST:OF:OBJECTS:OF:CLASS)
25100 (PUT CLASS:NAME MAYBE:RELATIONS SET:OF:MAYBE:RELATIONS)
25200 (RETURN SET:OF:MAYBE:RELATIONS)))
25300 (SETQ OLD:4 (CAR LIST:OF:OBJECTS:OF:CLASS))
25400 (SETQ NEW:4 (CAR NEW:LIST:OF:OBJECTS:OF:CLASS))
25500 (SUBSTITUTE NEW:4 FOR OLD:4 IN SET:OF:MAYBE:RELATIONS)
25600 (GO LABEL:4)
25700 )
25800 )))
25900 This completes the code for RE:WRITE:4. Notice that we must still adapt
26000 SUBSTITUTE to this particular call.
26100
26200 COMMENT
26300 The substitute is the simple "find all occurrences and replace
26400 them by the new item" type, no special permanent copies or other messy
26500 details to worry about. We note that the way the function is defined,
26600 the two USING sets may be of different lenghts, yet the way the
26700 RENAME functions are written, they will always be the same length.
26800 If the RENAMEing isn't changed, we can eliminate one half of the
26900 termination check. In fact, this function is really just a cumbersome
27000 form of MAP2CAR, as it now stands. We may later replace it entirely
27100 by a call to this latter function.
27200 end of COMMENT
27300
27400 end of ENCODE
27500
27600 end of ADAPT:PRECONCEIVED:FUNCTION
27700
27800 Back in REPEATEDLY loop.
27900
28000 ADAPT:PRECONCEIVED:FUNCTION
28100 We again have a slew of re:write functions, plus one substitute
28200 function. Again, the choice both seems and is arbitrary. Say we pick
28300 the substitute function to work on.
28400
28500 ENCODE
28600 We create a new context, replace SUBSTITUTE by SUBSTITUTE:4,
28700 and look at the preconception of the function. It is almost a primitive
28800 function, and sure enough no special modifications are necessary now.
28900 (DEFINEQ (SUBSTITUTE:4 (LAMBDA (NEW:4 FOR OLD:4 IN SET:OF:MAYBE:RELATIONS)
29000 (COND ((NULL SET:OF:MAYBE:RELATIONS) NIL)
29100 ((LISTP SET:OF:MAYBE:RELATIONS)
29200 (CONS (SUBSTITUTE:4 NEW:4 FOR OLD:4 IN (CAR SET:OF:MAYBE:RELATIONS))
29300 (SUBSTITUTE:4 NEW:4 FOR OLD:4 IN (CDR SET:OF:MAYBE:RELATIONS))))
29400 ((EQUAL SET:OF:MAYBE:RELATIONS OLD:4) NEW:4)
29500 (T SET:OF:MAYBE:RELATIONS))
29600 )))
29700
29800 COMMENT
29900 We must have IN and FOR initialized.
30000 We note that this is the same as the last substitute fn., and if it
30100 remains so, we can later combine them into one function.
30200 end of COMMENT
30300
30400 end of ENCODE
30500
30600 end of ADAPT:PRECONCEIVED:FUNCTION
30700
30800 Well, we are once more in the outermost REPEATEDLY loop.
30900
31000 ADAPT:PRECONCEIVED:FUNCTION
31100 We have only the final two re:write functions left to adapt.
31200 Say we choose to do RE:WRITE:5 now.
31300
31400 ENCODE
31500 We create a new context, and examine the task.
31600 We know that re:writing using just one list essentially means
31700 setting the first list to the USING list. In addition, we must
31800 store the USING list in place of the permanent copy of the
31900 initial list, if one exists. In our case, no permanent copy of the
32000 LIST:OF:OBJECTS:OF:ELEMENT exists, so the function collapses to:
32100 (DEFINEQ (RE:WRITE:5 (LAMBDA
32200 (LIST:OF:OBJECTS:OF:ELEMENT USING NEW:LIST:OF:OBJECTS:OF:ELEMENT)
32300 (SETQ LIST:OF:OBJECTS:OF:ELEMENT NEW:LIST:OF:OBJECTS:OF:ELEMENT)
32400 )))
32500 This is asserted and evalled. The coding for the function is done.
32600
32700 COMMENT
32800 We note that the function could be replaced by the
32900 single SETQ that is its body. If this remains true at the completion
33000 of CF, we will do so. Note this isn't true for the other re:write
33100 functions.
33200 end of COMMENT
33300
33400 end of ENCODE
33500
33600 end of ADAPT:PRECONCEIVED:FUNCTION
33700
33800 Well, we are once more in the outermost REPEATEDLY loop.
33900
34000 ADAPT:PRECONCEIVED:FUNCTION
34100 We have only the final re:write function left to adapt.
34200 Say we choose to do RE:WRITE:6 now.
34300
34400 ENCODE
34500 We create a new context, and examine the task.
34600 We know that re:writing using just one list essentially means
34700 setting the first list to the USING list. In addition, we must
34800 store the USING list in place of the permanent copy of the
34900 initial list, if one exists. In our case, a permanent copy of the
35000 LIST:OF:OBJECTS:OF:CLASS exists, so the function is:
35100 (DEFINEQ (RE:WRITE:6 (LAMBDA
35200 (LIST:OF:OBJECTS:OF:CLASS USING NEW:LIST:OF:OBJECTS:OF:CLASS)
35300 (SETQ LIST:OF:OBJECTS:OF:CLASS NEW:LIST:OF:OBJECTS:OF:CLASS)
35400 (PUT CLASS:NAME CLASS:OBJECTS NEW:LIST:OF:CLASS:OBJECTS)
35500 )))
35600 This is asserted and evalled. The coding for the function is done.
35700
35800 COMMENT
35900 end of COMMENT
36000
36100 end of ENCODE
36200
36300 end of ADAPT:PRECONCEIVED:FUNCTION
36400 Back in REPEATEDLY loop.
36500
36600 CLARIFY:IMPROBABLE:SITUATION
36700
36800 CHOOSE:FROM
36900 We see that an analogous situation occurs just after we read in
37000 the correct class name: we don't really use it. How could we? Well,
37100 maybe the same way that we used class:name if it was supplied originally.
37200 In other words, we might want to reconcile it with the pre:existing
37300 class. Basically, this would involve copies of all the previous
37400 RECONCILE, FOREACH, TRANSFER, RENAME, REWRITE, and SUBSTITUTE functions,
37500 with CLASS:NAME replaced by CORRECT:CLASS:NAME. We decide that this
37600 is worth investigating now.
37700 end of CHOOSE:FROM
37800
37900 MESSAGE
38000 Asks the user if this is what he wants.
38100 end of MESSAGE
38200
38300 Say the user answers positively. Then the copies are made,
38400 CORRECT:CLASS:NAME is used, and the original call to the new
38500 function corresponding to RECONCILE:1 is placed as a final clause
38600 of the COND in ASK:FOR:1, namely
38700 ((MEMBER CORRECT:CLASS:NAME LIST:OF:POSSIBLE:CLASS:NAMES)
38800 (RECONCILE:1:counterpart CORRECT:CLASS:NAME ELEMENT))
38900 We won't dwell on this now; suffice it to say that all the functions
39000 are copied with out the logical reasoning steps. We comment heavily the
39100 fact that since RECONCILE:1 and its counterpart differ only in names
39200 of arguments, we could get by with the code we have, and just use the
39300 same functions called with CORRECT:CLASS:NAME initially. This assumes that
39400 class:name is passed as an argument to each function which uses it.
39500 We go through and change any exceptions to this. At the completion
39600 of CF, we may well be able to eliminate all these new functions. Since
39700 we in fact can, I won't spend any time on them here.
39800 end of CLARIFY:IMPROBABLE:SECTION
00100 Back in the outermost REPEATEDLY loop. This time,
00200 though, we have nothing left to do but get I/O format
00300 details, and resolve the few decisions still remaining.
00400 Most of these latter decisions generally won't be triggered until
00500 there is virtually nothing left undone in the CF task.
00600 Most of the format details are gotten via examples,
00700 example sessions, and so on, and thus this is almost
00800 a primitive for Pup. We will be scant on details of this
00900 part for this reason; i.e., Pup doesn't "think" too much about
01000 synthesis of strucutral types of list manipulation functions,
01100 so we won't either.
01200
01300 FIX:INCORRECT:PIECE
01400 Before going after the I/O, we should endeavor to complete all
01500 the little details we can. This might uncover a big subtask as yet
01600 undone; at least it will ease the insertion of the PRINT statements.
01700
01800 CHOOSE:FROM
01900 Say we decide that we'd like to take care of the initializations
02000 that have accumulated.
02100 end of CHOOSE:FROM
02200
02300 We merley have to add the new ones to the function INITIALIZE:1.
02400 These include assignments to FROM, TO, USING,... to
02500 (QUOTE FROM), (QUOTE TO), (QUOTE USING),... and we won't delve deeper.
02600 end of FIX:INCORRECT:PIECE
02700
02800 OBEY:DEMON
02900 Suppose the demons concerning backtracking are awakened. We find
03000 no new clues about this, so we ask.
03100
03200 MESSAGE
03300 "Pup: I may err in my choice of which relations to transfer.
03400 If I do err, should I be able to recall which relations I made my
03500 random choice from, and (i) transfer the incorrect relation to
03600 the MAYBE relations, (ii) replace it with another element chosen
03700 randomly from this old alternative set? Another possibility is
03800 to choose from elements in both the current MAYBE relations and in
03900 the old alternative set. Reply (a) for the first plan, (b) for the
04000 second plan, (c) to do nothing except (i), (d) to have me try to
04100 get more alternatives for you, (e) if you want to tell me something
04200 else to do about this."
04300 end of MESSAGE
04400
04500 Say user types (c). So we needn't do anything about this
04600 backtracking. Since this is a relatively firm decision, we create a
04700 new context and wipe out all the notes about backtracking which we'd
04800 written.
04900 end of OBEY:DEMON
05000
05100 OBEY:DEMON
05200 The second demon we spoke of above now has the floor.
05300
05400 MESSAGE
05500 "Pup: Another source of error in transferring from MAYBE to
05600 YES relations can arise as follows: a relation is in the MAYBE category,
05700 but it has not been present in every example of the class. Since this
05800 latter fact is not known to the system, the relation might be the one
05900 selected to be transferred to the YES set. One remedy would be to
06000 separate those MAYBE relations which always were present from those
06100 MAYBE relations which sometimes were present and sometimes were absent.
06200 Then we would only look through the first set for possibilities to
06300 transfer to YES relations set. Type OK, or else tell me what I should do."
06400 end of MESSAGE
06500
06600 Suppose the user types "Do nothing." Then we just go on. {For a second
06700 let us consider what we'd do if he typed ok. We'd look at all the relevant
06800 notes and make all the little changes. First, we have to get names for these
06900 two different sets. We get some plausible names and ask the user. Say
07000 we decide on ALWAYS:WAS and SOMETIMES. Then we realize that each preious
07100 use of MAYBE must be replaced by one of these sets, or by their union.
07200 In addition, we must transfer from the first to the second, conditionally.
07300 Looking over the code, we see that in DETERMINE:1, near the end, we
07400 do the transferring to YES relations. We therefore replace the occurence
07500 of MAYBE there by ALWAYS:WAS. We proceed in this manner...}
07600 end of OBEY:DEMON
07700 OBEY:DEMON
07800 We finally get around to settling decision (17),
07900 now that we possess a full understanding of how the determination
08000 process could err. Lo and behold, almost all of the points the demon
08100 raises are already answered. We can rule out (b) and (c), so we
08200 are left with (a): that is, nothing! So here we see how we have
08300 acquired enough knowledge to dispense with bothering the user.
08400 This is one of the reasons we try to defer so much.
08500 end of OBEY:DEMON
08600
08700
08800 Back in outer REPEATEDLY (CHOOSE:FROM) loop. We still have some
08900 demons tugging at our sleeves. Notice that the decision (1) demon
09000 has an earlier surfacing condition that the decision (9) demon.
09100 We interpret this as: if you have to ask about demon (9), ask about
09200 (1) first. We are now at the point of asking about (9), so we wait
09300 on it just a little longer.
09400
09500 OBEY:DEMON
09600 We shall dispose of the decision (1) problem: whether we are working
09700 on classificatory, comparitive, or metric concept formation. We have
09800 no new knowlege. Can we defer at least part of the decision? Yes, using
09900 identical reasoning as before (in WHEN:NEXT, to arrive at the old
10000 deferral condition of (1)) we see that the latter two types of concept
10100 formation have the nontrivial intersection "linearly order the
10200 equivalence classes". So all we need do at the present time is ask
10300 whether the task is (a) classificatory only, or (b) involves more
10400 (i.e., comparative or metric).
10500
10600 MESSAGE
10700 We pose this to the user
10800 end of MESSAGE
10900
11000 Say he types back (a). So we know that CF won't have any more
11100 functions added to it. Nothing need be done then at this time.
11200 end of OBEY:DEMON
11300
11400 OBEY:DEMON
11500 We have not yet decided whether the lists
11600 LIST:OF:POSSIBLE:CLASS:NAMES, LIST:OF:OBJECTS:OF:ELEMENT,
11700 SET:OF:RELATIONS are ordered, and, if so, what the orderings are.
11800 We have the names already, though. They are, respectively,
11900 CLASS:NAMES:ORDERING, ELEMENT:OBJECTS:ORDERING,
12000 ELEMENT:RELATIONS:ORDERING. We already noticed the need to define the
12100 first of these. The second and third should only be defined if
12200 we do any insertions into the objects or relations of ELEMENT, which
12300 we never do. Thus we note that they may be utterly forgotten.
12400 We worry about the first ordering now. We tentatively search through
12500 the list of class names in order, accepting the first match. Thus
12600 the order is fairly important. We ask the user:
12700
12800 MESSAGE
12900 "Pup: I search the list of possible class names in order.
13000 What order should I maintain them in?"
13100 end of MESSAGE
13200
13300 Say user types "in order of decreasing age". This gets
13400 translated to mean that insertions are at the front.
13500
13600 ENCODE
13700 Using programming knowledge, we create a context and then define
13800 the ordering in such a way that the MERGE using it becomes a CONS.
13900 We know that this is accomplished by defining the ordering to be
14000 the constant function T. In particular we have
14100 (DEFINEQ (CLASS:NAMES:ORDERING (LAMBDA (A B) T)))
14200 and also we have the supplied function merge:
14300 (DEFINEQ (MERGE (LAMBDA (NEW LIST ORDER)
14400 (COND ((NULL LIST) (CONS NEW LIST))
14500 ((ORDER NEW (CAR LIST)) (CONS NEW LIST))
14600 (T (CONS (CAR LIST) (MERGE NEW (CDR LIST) ORDER))))
14700 )))
14800
14900 COMMENT
15000 We notice that if we aren't told something different, we can
15100 ultimately replace any MERGE statement using CLASS:NAMES:ORDERING by
15200 a simple CONS statement.
15300 end of COMMENT
15400
15500 end of ENCODE
15600
15700 end of OBEY:DEMON
15800
15900 Back in the outermost loop, the REPEATEDLY (CHOOSE:FROM). Notice
16000 that we are not looping back here these past few times; we are in the
16100 same iteration, but we keep being interrupted by demons before we
16200 can choose something from our list of five functions.
16300
16400 OBEY:DEMON
16500 Before deciding all the I/O formats, we look around for specifics.
16600 We see in INPUT:1 that the functions corresponding:part:of:element
16700 are still not defined. These will be, now. We see that they look at
16800 the newly read in ELEMENT, and extract (using structural manipulations,
16900 compositions of simple list processing functions) LIST:OF:OBJECTS:OF:ELEMENT
17000 and CLASS:NAME (two separate functions).
17100
17200 ENCODE
17300 We create a new context, call the function
17400 CORRESPONDING:OBJECTS:PART:OF:ELEMENT, and look at the notes we made about
17500 it. We see that what we should do is ask for a prototype ELEMENT,
17600 check that its CAR is in fact class name, and try to synthesize the
17700 current function directly. We ask the user:
17800
17900 pup: please give me an example of the way you will type in an element.
18000 let the element have class:name equal to NAME, object list equal to
18100 (ob1 ob2 ob3 ob4 ob5 ob6 ob7 ob8 ob9 ob10), and set of relations equal to
18200 ((rel1 ob1 ob2) (rel2 ob5 ob4) (rel3 ob3 ob4) (rel4 ob10)
18300 (rel5 ob6 ob7 ob8) (rel6) (rel7 ob9 ob9)). Go ahead...
18400
18500 (NAME (OB1 OB2 OB3 OB4 OB5 OB6 OB7 OB8 OB9 OB10) (REL1 OB1 OB2)
18600 (REL2 OB5 OB4) (REL3 OB3 OB4) (REL4 OB10) (REL5 OB6 OB7 OB8) (REL6)
18700 (REL7 OB9 OB9)).
18800
18900 From this we synthesize easily:
19000 (DEFINEQ (CORRESPONDING:OBJECTS:PART:OF:ELEMENT (LAMBDA (ELEMENT)
19100 (CADR ELEMENT)
19200 )))
19300
19400 We also make the call in INPUT:1 read as follows:
19500 (CORRESPONDING:OBJECTS:PART:OF:ELEMENT ELEMENT).
19600
19700 COMMENT
19800 We note that the call could be replaced by the single:statement
19900 body, i.e., by the function CADR. We will do this later, in the
20000 optimization phase, if the definition stands.
20100 end of COMMENT
20200
20300 end of ENCODE
20400
20500 ENCODE
20600 Almost as easily, we look at the prototype ELEMENT and get:
20700 (DEFINEQ (CORRESPONDING:RELATIONS:PART:OF:ELEMENT (LAMBDA (ELEMENT)
20800 (CDDR ELEMENT)
20900 )))
21000 The call is replaced, and a similar comment asserted.
21100 end of ENCODE
21200
21300 end of OBEY:DEMON
21400
21500 OBEY:DEMON
21600 We are now going to put demon (23) to rest. This worries about
21700 whether or not to output something during the HALT function. We
21800 have a note saying this is very probable. We look up outputting
21900 and find some decisions to be made:
22000
22100 TYPE
22200 There are a few types of things to decide
22300 (25) Where does the output go Alternatives: teletype (= user),
22400 line printer, auxilliary disk file.
22500 Affect: Specific output commands issued. Coding of the output
22600 statements.
22700 (26) Under what conditions do we do the outputting Alternatives:
22800 unconditionally, if asked, we ask and then if ok'ed.
22900 Affect: same as (25) effect
23000 (27) We must know (precondition perhaps) exactly what is to be outputted
23100 Affect: Specific output commands issued. Coding of the output
23200 statemennts.
23300 end of TYPE
23400
23500 So we really must answer all of these before firmly deciding how the
23600 output routines should be written.
23700
23800 OBEY:DEMON
23900 We ask the user about (25).
24000
24100 MESSAGE
24200 "Pup: Just after you type me an ELEMENT whose CLASS NAME
24300 is HALT, I enter a special halt routine. In addition to answering
24400 your HALT by a query as to whther or not you want to continue, I
24500 assume that I write some information out. If yes, then where do
24600 I do this outputting: (a) to you (b) printer (c) disk file (d) noneα
24700 end of MESSAGE
24800
24900 Say the user replies (c). So we call in the disk-dumping
25000 output routine template.
25100 end of OBEY:DEMON
25200
25300 OBEY:DEMON
25400 We ask about (26). Say user replies that we do the outputting
25500 unconditionally. That makes life a little easier.
25600 end of OBEY:DEMON
25700
25800 OBEY:DEMON
25900 On (27), say we ask and find out the answer to be:
26000 "Output the list of possible class names and the associated
26100 class descriptions." This gets translated to (OUTPUT
26200 LIST:OF:POSSIBLE:CLASS:NAMES) with a note that
26300 the type of outputting is the strong kind: all associated structures
26400 are dumped also.
26500 end of OBEY:DEMON
26600
26700 To fully satiate demon (23), we actually get the output routine
26800 code.
26900
27000 ENCODE
27100 We know the template from (25), we pull out the COND
27200 because of (26), and we know how to instantiate it because of
27300 (27). We get something like:
27400 (DEFINEQ (OUTPUT:1 (LAMBDA (LIST:OF:POSSIBLE:CLASS:NAMES)
27500 (FOREACH POSSIBLE:CLASS:NAME IN LIST:OF:POSSIBLE:CLASS:NAMES DO
27600 (DISK:DUMP file:name (LIST POSSIBLE:CLASS:NAME
27700 (GET POSSIBLE:CLASS:NAME CLASS:OBJECTS)
27800 (GET POSSIBLE:CLASS:NAME CLASS:RELATIONS)))
27900 )
28000 )))
28100 We know that the FOREACH is the MAPCAR kind, and we don't ever worry
28200 about it. We also treat DISK:DUMP and LIST as primitives. All that
28300 remains is to get the file name the user wants. We'd better ask him.
28400
28500 GET:NAME
28600 Say we ask and he tells us "Ask me at the beginning of
28700 each run of the concept formation program." This is translated
28800 to mean: insert (ASK:FOR:2 FILE:NAME) at a point of the
28900 flow of control which is near the beginning of CF. We
29000 decide to stick it at the end of INITIALIZE:1. We also replace
29100 file:name above by FILE:NAME, recognizing it as a dummy variable
29200 and not worth asking the user about its name.
29300 end of GET:NAME
29400
29500 end of ENCODE
29600
29700 ENCODE
29800 We do ASK:FOR:2. It is just
29900 the same as the other ask for function, but without the late
30000 COND additions stuck on.
30100 end of ENCODE
30200
30300 end of OBEY:DEMON
30400
30500 Back in outer loop again. Again we haven't chosen, just keep
30600 responding to demons.
30700
30800 OBEY:DEMON
30900 Pup is finally going to worry about (9), the specific formatting
31000 and outputting details. We do this before optimization, but after all else.
31100 There are several alternatives open to Pup. It can ask for a sample
31200 session, as an example, and then simulate the operation of CF, thereby
31300 determining what gets typed where. This is most effective when some or
31400 most of the output statements are already present (although the exact
31500 formats needn't be there) and all or almost all of the input statements
31600 are similarly "located." Thus we work first on getting as much
31700 general information as we can, about where we read/write which things.
31800 We t